[jira] [Updated] (AMBARI-12263) Support PAM as authentication mechanism for accessing Ambari UI/REST
[ https://issues.apache.org/jira/browse/AMBARI-12263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Ghugare updated AMBARI-12263: Status: Open (was: Patch Available) > Support PAM as authentication mechanism for accessing Ambari UI/REST > > > Key: AMBARI-12263 > URL: https://issues.apache.org/jira/browse/AMBARI-12263 > Project: Ambari > Issue Type: Story > Components: ambari-server, ambari-web >Affects Versions: trunk >Reporter: Eric Yang >Assignee: Vishal Ghugare > Labels: security > Fix For: trunk > > Attachments: AMBARI-12263.patch, PAM Support.doc > > > Ambari GUI is using default "admin" user which is not a real user in > operating system. Some company has strict password policy which can not be > enforced to Ambari. It would be good to implement a Shiro PAM connector to > authenticate user by Linux user credential. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18696) Add Hive View Links to Hive Summary Page
[ https://issues.apache.org/jira/browse/AMBARI-18696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Zang updated AMBARI-18696: -- Status: Patch Available (was: Open) > Add Hive View Links to Hive Summary Page > > > Key: AMBARI-18696 > URL: https://issues.apache.org/jira/browse/AMBARI-18696 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Richard Zang >Assignee: Richard Zang > Fix For: 2.5.0 > > Attachments: AMBARI-18696.patch > > > Add Hive View Links to Hive Summary Page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18696) Add Hive View Links to Hive Summary Page
[ https://issues.apache.org/jira/browse/AMBARI-18696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Zang updated AMBARI-18696: -- Attachment: AMBARI-18696.patch > Add Hive View Links to Hive Summary Page > > > Key: AMBARI-18696 > URL: https://issues.apache.org/jira/browse/AMBARI-18696 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Richard Zang >Assignee: Richard Zang > Fix For: 2.5.0 > > Attachments: AMBARI-18696.patch > > > Add Hive View Links to Hive Summary Page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18696) Add Hive View Links to Hive Summary Page
Richard Zang created AMBARI-18696: - Summary: Add Hive View Links to Hive Summary Page Key: AMBARI-18696 URL: https://issues.apache.org/jira/browse/AMBARI-18696 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.5.0 Reporter: Richard Zang Assignee: Richard Zang Fix For: 2.5.0 Add Hive View Links to Hive Summary Page -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18695) Add PXF Hive ORC Profile
[ https://issues.apache.org/jira/browse/AMBARI-18695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt updated AMBARI-18695: -- Attachment: AMBARI-18695-trunk-orig.patch > Add PXF Hive ORC Profile > > > Key: AMBARI-18695 > URL: https://issues.apache.org/jira/browse/AMBARI-18695 > Project: Ambari > Issue Type: Improvement > Components: stacks >Affects Versions: trunk, 2.5.0, 2.4.2 >Reporter: Matt >Assignee: Matt >Priority: Minor > Fix For: trunk, 2.5.0, 2.4.2 > > Attachments: AMBARI-18695-trunk-orig.patch > > > Add PXF Hive ORC Profile -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18695) Add PXF Hive ORC Profile
[ https://issues.apache.org/jira/browse/AMBARI-18695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt updated AMBARI-18695: -- Status: Patch Available (was: Open) > Add PXF Hive ORC Profile > > > Key: AMBARI-18695 > URL: https://issues.apache.org/jira/browse/AMBARI-18695 > Project: Ambari > Issue Type: Improvement > Components: stacks >Affects Versions: trunk, 2.5.0, 2.4.2 >Reporter: Matt >Assignee: Matt >Priority: Minor > Fix For: trunk, 2.5.0, 2.4.2 > > Attachments: AMBARI-18695-trunk-orig.patch > > > Add PXF Hive ORC Profile -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18695) Add PXF Hive ORC Profile
Matt created AMBARI-18695: - Summary: Add PXF Hive ORC Profile Key: AMBARI-18695 URL: https://issues.apache.org/jira/browse/AMBARI-18695 Project: Ambari Issue Type: Improvement Components: stacks Affects Versions: trunk, 2.5.0, 2.4.2 Reporter: Matt Assignee: Matt Priority: Minor Fix For: trunk, 2.5.0, 2.4.2 Add PXF Hive ORC Profile -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMBARI-18694) Add JVM settings of forcing garbage collections to release DataNode heap
[
https://issues.apache.org/jira/browse/AMBARI-18694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobing Zhou reassigned AMBARI-18694:
--
Assignee: Xiaobing Zhou
> Add JVM settings of forcing garbage collections to release DataNode heap
>
>
> Key: AMBARI-18694
> URL: https://issues.apache.org/jira/browse/AMBARI-18694
> Project: Ambari
> Issue Type: Improvement
>Reporter: Xiaobing Zhou
>Assignee: Xiaobing Zhou
>
> As HDFS-11047 reported, DirectoryScanner does scan by deep copying
> FinalizedReplica. In a deployment with 500,000+ blocks, we've seen the DN
> heap usage being accumulated to high peaks very quickly. Deep copies of
> FinalizedReplica will make DN heap usage even worse if directory scans are
> scheduled more frequently.
> Another factor is that huge number of ScanInfo instances corresponding to
> HDFS blocks are lingering in garbage to eat many heap memories until a full
> GC takes place.
> This proposes adding JVM settings to force GC more frequently to release
> DataNode heap consumed as a result of two aforementioned reasons, i.e. add
> the options to HADOOP_DATANODE_OPTS
> {noformat}
> -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly
> -XX:ConcGCThreads=8 -XX:+UseConcMarkSweepGC
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18694) Add JVM settings of forcing garbage collections to release DataNode heap
[
https://issues.apache.org/jira/browse/AMBARI-18694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobing Zhou updated AMBARI-18694:
---
Summary: Add JVM settings of forcing garbage collections to release
DataNode heap (was: Add JVM settings of forcing garbage collections to
alleviate heap consumption on DataNode)
> Add JVM settings of forcing garbage collections to release DataNode heap
>
>
> Key: AMBARI-18694
> URL: https://issues.apache.org/jira/browse/AMBARI-18694
> Project: Ambari
> Issue Type: Improvement
>Reporter: Xiaobing Zhou
>
> As HDFS-11047 reported, DirectoryScanner does scan by deep copying
> FinalizedReplica. In a deployment with 500,000+ blocks, we've seen the DN
> heap usage being accumulated to high peaks very quickly. Deep copies of
> FinalizedReplica will make DN heap usage even worse if directory scans are
> scheduled more frequently.
> Another factor is that huge number of ScanInfo instances corresponding to
> HDFS blocks are lingering in garbage to eat many heap memories until a full
> GC takes place.
> This proposes adding JVM settings to force GC more frequently to release
> DataNode heap consumed as a result of two aforementioned reasons, i.e. add
> the options to HADOOP_DATANODE_OPTS
> {noformat}
> -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly
> -XX:ConcGCThreads=8 -XX:+UseConcMarkSweepGC
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18694) Add JVM settings of forcing garbage collections to alleviate heap consumption on DataNode
[
https://issues.apache.org/jira/browse/AMBARI-18694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaobing Zhou updated AMBARI-18694:
---
Description:
As HDFS-11047 reported, DirectoryScanner does scan by deep copying
FinalizedReplica. In a deployment with 500,000+ blocks, we've seen the DN heap
usage being accumulated to high peaks very quickly. Deep copies of
FinalizedReplica will make DN heap usage even worse if directory scans are
scheduled more frequently.
Another factor is that huge number of ScanInfo instances corresponding to HDFS
blocks are lingering in garbage to eat many heap memories until a full GC takes
place.
This proposes adding JVM settings to force GC more frequently to release
DataNode heap consumed as a result of two aforementioned reasons, i.e. add the
options to HADOOP_DATANODE_OPTS
{noformat}
-XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly
-XX:ConcGCThreads=8 -XX:+UseConcMarkSweepGC
{noformat}
> Add JVM settings of forcing garbage collections to alleviate heap consumption
> on DataNode
> -
>
> Key: AMBARI-18694
> URL: https://issues.apache.org/jira/browse/AMBARI-18694
> Project: Ambari
> Issue Type: Improvement
>Reporter: Xiaobing Zhou
>
> As HDFS-11047 reported, DirectoryScanner does scan by deep copying
> FinalizedReplica. In a deployment with 500,000+ blocks, we've seen the DN
> heap usage being accumulated to high peaks very quickly. Deep copies of
> FinalizedReplica will make DN heap usage even worse if directory scans are
> scheduled more frequently.
> Another factor is that huge number of ScanInfo instances corresponding to
> HDFS blocks are lingering in garbage to eat many heap memories until a full
> GC takes place.
> This proposes adding JVM settings to force GC more frequently to release
> DataNode heap consumed as a result of two aforementioned reasons, i.e. add
> the options to HADOOP_DATANODE_OPTS
> {noformat}
> -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly
> -XX:ConcGCThreads=8 -XX:+UseConcMarkSweepGC
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18694) Add JVM settings of forcing garbage collections to alleviate heap consumption on DataNode
Xiaobing Zhou created AMBARI-18694: -- Summary: Add JVM settings of forcing garbage collections to alleviate heap consumption on DataNode Key: AMBARI-18694 URL: https://issues.apache.org/jira/browse/AMBARI-18694 Project: Ambari Issue Type: Improvement Reporter: Xiaobing Zhou -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18375) Ranger Plugin configs are not generated for Hive interactive
[ https://issues.apache.org/jira/browse/AMBARI-18375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-18375: --- Fix Version/s: (was: 2.4.2) (was: 2.4.1) 2.5.0 > Ranger Plugin configs are not generated for Hive interactive > > > Key: AMBARI-18375 > URL: https://issues.apache.org/jira/browse/AMBARI-18375 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Mugdha Varadkar >Assignee: Mugdha Varadkar >Priority: Blocker > Fix For: 2.5.0 > > Attachments: AMBARI-18375.patch > > > If audit to hdfs is OFF for ranger hive plugin, configs related to plugins > are not generated for Hive interactive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-17783) Add falcon to oozie admin user for HDP 2.5
[ https://issues.apache.org/jira/browse/AMBARI-17783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606376#comment-15606376 ] Tim Thorpe commented on AMBARI-17783: - [~venkatnrangan] Not sure I understand the difference between what you had in your patch 2 and just using the services. The clusterData components are calculated using the services: https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/stacks/stack_advisor.py#L725 https://github.com/apache/ambari/blob/trunk/ambari-server/src/main/resources/stacks/HDP/2.0.6/services/stack_advisor.py#L902 Looks like I'm going to need to figure out another way of determining if Falcon is installed. > Add falcon to oozie admin user for HDP 2.5 > -- > > Key: AMBARI-17783 > URL: https://issues.apache.org/jira/browse/AMBARI-17783 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Murali Ramasami >Assignee: Venkat Ranganathan > Fix For: 2.4.0 > > Attachments: AMBARI-17783.patch, AMBARI-17783.patch.2 > > > we need to add falcon and falcon-admin in the oozie_admin_users of oozie > advanced env section. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18683) Argument for manually setting CURRENT is unclear
[
https://issues.apache.org/jira/browse/AMBARI-18683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18683:
---
Fix Version/s: (was: 2.5.0)
3.0.0
> Argument for manually setting CURRENT is unclear
>
>
> Key: AMBARI-18683
> URL: https://issues.apache.org/jira/browse/AMBARI-18683
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
> Fix For: 3.0.0
>
>
> It is currently possible to set the CURRENT {{repo_version}} for a component.
> The API is a little misleading. The call below should also check for the
> version string, not just the display name. Could also check for the id itself
> too.
> {noformat}
> PUT /api/v1/clusters/c1/stack_versions
> {
> "ClusterStackVersions": {
> "force": true,
> "state": "CURRENT",
> "repository_version": "HDP-2.5.1.0"<--- must be display name
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18683) Argument for manually setting CURRENT is unclear
[
https://issues.apache.org/jira/browse/AMBARI-18683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18683:
---
Issue Type: Bug (was: Task)
> Argument for manually setting CURRENT is unclear
>
>
> Key: AMBARI-18683
> URL: https://issues.apache.org/jira/browse/AMBARI-18683
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
> Fix For: 3.0.0
>
>
> It is currently possible to set the CURRENT {{repo_version}} for a component.
> The API is a little misleading. The call below should also check for the
> version string, not just the display name. Could also check for the id itself
> too.
> {noformat}
> PUT /api/v1/clusters/c1/stack_versions
> {
> "ClusterStackVersions": {
> "force": true,
> "state": "CURRENT",
> "repository_version": "HDP-2.5.1.0"<--- must be display name
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18681) StackVersionListener should check for cluster version
[
https://issues.apache.org/jira/browse/AMBARI-18681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18681:
---
Description:
For Host Ordered upgrades, add host information and type to the structured out.
The response should contain:
{noformat}
"Tasks": {
"attempt_cnt": 1,
"cluster_name": "c1",
"command": "EXECUTE",
"command_detail": "All services have been stopped on c6401.ambari.apache.org.
Please prepare the new host and then proceed.",
"custom_command_name":
"org.apache.ambari.server.serveraction.upgrades.ManualStageAction",
"role": "AMBARI_SERVER_ACTION",
...
"status": "HOLDING",
"stderr": "",
"stdout": "",
"structured_out": {
"type": "HOST_PREPARE"
"host": "c6401.ambari.apache.org"
}
}
{noformat}
was:
While doing the POC for Offline Upgrades, the StackVersionListener was trying
to add duplicate records based on version.
{noformat}
Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services -
2.6.2.v20151217-774c696): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLException: ERROR: duplicate key
value violates unique constraint "uq_repo_version_stack_id"
Detail: Key (stack_id, version)=(2, 2.5.1.0-30) already exists.
Error Code: 0
Call: UPDATE repo_version SET version = ? WHERE (repo_version_id = ?)
bind => [2 parameters bound]
at
org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:340)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processExceptionForCommError(DatabaseAccessor.java:1620)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:900)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeNoSelect(DatabaseAccessor.java:964)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:633)
at
org.eclipse.persistence.internal.databaseaccess.ParameterizedSQLBatchWritingMechanism.executeBatch(ParameterizedSQLBatchWritingMechanism.java:149)
at
org.eclipse.persistence.internal.databaseaccess.ParameterizedSQLBatchWritingMechanism.executeBatchedStatements(ParameterizedSQLBatchWritingMechanism.java:134)
at
org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.writesCompleted(DatabaseAccessor.java:1845)
at
org.eclipse.persistence.internal.sessions.AbstractSession.writesCompleted(AbstractSession.java:4300)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.writesCompleted(UnitOfWorkImpl.java:5592)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.acquireWriteLocks(UnitOfWorkImpl.java:1646)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitTransactionAfterWriteChanges(UnitOfWorkImpl.java:1614)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitRootUnitOfWork(RepeatableWriteUnitOfWork.java:285)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResume(UnitOfWorkImpl.java:1169)
at
org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commit(EntityTransactionImpl.java:134)
at
org.apache.ambari.server.orm.AmbariJpaLocalTxnInterceptor.invoke(AmbariJpaLocalTxnInterceptor.java:153)
at
org.apache.ambari.server.events.listeners.upgrade.StackVersionListener.onAmbariEvent(StackVersionListener.java:106)
at sun.reflect.GeneratedMethodAccessor179.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74)
at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322)
at
com.google.common.eventbus.EventBus.dispatchQueuedEvents(EventBus.java:304)
at com.google.common.eventbus.EventBus.post(EventBus.java:275)
at
org.apache.ambari.server.events.publishers.VersionEventPublisher.publish(VersionEventPublisher.java:52)
at
org.apache.ambari.server.agent.HeartbeatProcessor.processCommandReports(HeartbeatProcessor.java:493)
at
org.apache.ambari.server.agent.HeartbeatProcessor.processHeartbeat(HeartbeatProcessor.java:213)
at
org.apache.ambari.server.agent.HeartbeatProcessor$HeartbeatProcessingTask.run(HeartbeatProcessor.java:188)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
[jira] [Updated] (AMBARI-18680) Add orchestration for HOST_ORDERED upgrades
[
https://issues.apache.org/jira/browse/AMBARI-18680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18680:
---
Description:
Orchestration via UpgradeHelper need to orchestrate via HOSTS instead of the
UpgradePack services. This will entail:
* Refactor UpgradeHelper to choose orchestration model
* Upgrade Pack changes are minimal, StageWrapper and Manual tasks are generated
in-code.
* Determine service check changes (if any)
was:
When invoking an Offline Upgrade, the server should be restricted for operation
by the web client.
* We can add a servlet filter to restrict this, then use a {{cluster-env}}
property to indicate when the API should be locked down.
* PUT/POST should all be disallowed
** Except when passing a custom header with calls that allows the functionality.
> Add orchestration for HOST_ORDERED upgrades
> ---
>
> Key: AMBARI-18680
> URL: https://issues.apache.org/jira/browse/AMBARI-18680
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.5.0
>
>
> Orchestration via UpgradeHelper need to orchestrate via HOSTS instead of the
> UpgradePack services. This will entail:
> * Refactor UpgradeHelper to choose orchestration model
> * Upgrade Pack changes are minimal, StageWrapper and Manual tasks are
> generated in-code.
> * Determine service check changes (if any)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18680) Add orchestration for HOST_ORDERED upgrades
[
https://issues.apache.org/jira/browse/AMBARI-18680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18680:
---
Summary: Add orchestration for HOST_ORDERED upgrades (was: Disallow POST
and PUT operations on a cluster)
> Add orchestration for HOST_ORDERED upgrades
> ---
>
> Key: AMBARI-18680
> URL: https://issues.apache.org/jira/browse/AMBARI-18680
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.5.0
>
>
> When invoking an Offline Upgrade, the server should be restricted for
> operation by the web client.
> * We can add a servlet filter to restrict this, then use a {{cluster-env}}
> property to indicate when the API should be locked down.
> * PUT/POST should all be disallowed
> ** Except when passing a custom header with calls that allows the
> functionality.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18679) Create HOST_ORDERED Upgrade Pack
[ https://issues.apache.org/jira/browse/AMBARI-18679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18679: --- Description: Create a new type of upgrade pack that allows an upgrade by Host Order. This JIRA is only creating the skeleton. The classes for HOST_ORDERED will be added as the feature progresses. (was: Create a new type of upgrade pack that allows an upgrade by Host Order) > Create HOST_ORDERED Upgrade Pack > > > Key: AMBARI-18679 > URL: https://issues.apache.org/jira/browse/AMBARI-18679 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Nate Cole >Priority: Critical > Fix For: 2.5.0 > > > Create a new type of upgrade pack that allows an upgrade by Host Order. This > JIRA is only creating the skeleton. The classes for HOST_ORDERED will be > added as the feature progresses. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18685) Add validations and attributes to support HOST_ORDERED upgrades
[
https://issues.apache.org/jira/browse/AMBARI-18685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18685:
---
Description:
Augment the API of creating an Upgrade with the following:
{noformat}
POST api/v1/clusters/c1/upgrades
{
"Upgrade": {
"repository_version": "2.5.0.0-965",
"upgrade_type": "HOST_ORDERED", <-- new value other than
ROLLING/NON_ROLLING
"skip_failures": "false",
"skip_prerequisite_checks": "false",
"skip_manual_verification": "false",
"host_order": ["c6401.ambari.apache.org", "c6402.ambari.apache.org",
"c6403.ambari.apache.org"] <-- new
}
{noformat}
{{skip_failures}} must be {{false}} when the upgrade_type is HOST_ORDERED
{{skip_manual_verification}} must be omitted or {{false}} when upgrade_type is
HOST_ORDERED
was:Use the API to set the desired version for a service. This API is at the
service layer, but the value will be used to set the component table only.
> Add validations and attributes to support HOST_ORDERED upgrades
> ---
>
> Key: AMBARI-18685
> URL: https://issues.apache.org/jira/browse/AMBARI-18685
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Jonathan Hurley
>Priority: Critical
> Fix For: 2.5.0
>
>
> Augment the API of creating an Upgrade with the following:
> {noformat}
> POST api/v1/clusters/c1/upgrades
> {
> "Upgrade": {
> "repository_version": "2.5.0.0-965",
> "upgrade_type": "HOST_ORDERED", <-- new value other than
> ROLLING/NON_ROLLING
> "skip_failures": "false",
> "skip_prerequisite_checks": "false",
> "skip_manual_verification": "false",
> "host_order": ["c6401.ambari.apache.org", "c6402.ambari.apache.org",
> "c6403.ambari.apache.org"] <-- new
> }
> {noformat}
> {{skip_failures}} must be {{false}} when the upgrade_type is HOST_ORDERED
> {{skip_manual_verification}} must be omitted or {{false}} when upgrade_type
> is HOST_ORDERED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18685) Add validations and attributes to support HOST_ORDERED upgrades
[ https://issues.apache.org/jira/browse/AMBARI-18685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Cole updated AMBARI-18685: --- Summary: Add validations and attributes to support HOST_ORDERED upgrades (was: Add API to set desired version for a cluster) > Add validations and attributes to support HOST_ORDERED upgrades > --- > > Key: AMBARI-18685 > URL: https://issues.apache.org/jira/browse/AMBARI-18685 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Nate Cole >Assignee: Jonathan Hurley >Priority: Critical > Fix For: 2.5.0 > > > Use the API to set the desired version for a service. This API is at the > service layer, but the value will be used to set the component table only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18679) Create HOST_ORDERED Upgrade Pack
[
https://issues.apache.org/jira/browse/AMBARI-18679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18679:
---
Description: Create a new type of upgrade pack that allows an upgrade by
Host Order (was: ClusterVersionResourceProvider should allow creating the
records for {{cluster_version}} and {{host_version}} directly as iNSTALLED.)
> Create HOST_ORDERED Upgrade Pack
>
>
> Key: AMBARI-18679
> URL: https://issues.apache.org/jira/browse/AMBARI-18679
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.5.0
>
>
> Create a new type of upgrade pack that allows an upgrade by Host Order
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18679) Create HOST_ORDERED Upgrade Pack
[
https://issues.apache.org/jira/browse/AMBARI-18679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate Cole updated AMBARI-18679:
---
Summary: Create HOST_ORDERED Upgrade Pack (was:
ClusterVersionResourceProvider should allow direct creation of Installed
Components)
> Create HOST_ORDERED Upgrade Pack
>
>
> Key: AMBARI-18679
> URL: https://issues.apache.org/jira/browse/AMBARI-18679
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Nate Cole
>Assignee: Nate Cole
>Priority: Critical
> Fix For: 2.5.0
>
>
> ClusterVersionResourceProvider should allow creating the records for
> {{cluster_version}} and {{host_version}} directly as iNSTALLED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18693) get_sysprep_skip_copy_tarballs_hdfs() always returns False
[
https://issues.apache.org/jira/browse/AMBARI-18693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18693:
---
Status: Patch Available (was: Open)
> get_sysprep_skip_copy_tarballs_hdfs() always returns False
> --
>
> Key: AMBARI-18693
> URL: https://issues.apache.org/jira/browse/AMBARI-18693
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
> Fix For: 3.0.0, 2.5.0
>
> Attachments: AMBARI-18693.patch
>
>
> {{get_sysprep_skip_copy_tarballs_hdfs()}} in
> {{ambari-common/src/main/python/resource_management/libraries/functions/copy_tarball.py}}
> looks for {{cluster-env}} in the wrong place, hence always returns
> {{False}}. This causes all scripts that use this function to unnecessarily
> copy to HDFS files that are already present in sysprepped environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18638) Include an option to upload query in hive-view
[ https://issues.apache.org/jira/browse/AMBARI-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606215#comment-15606215 ] Hudson commented on AMBARI-18638: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #201 (See [https://builds.apache.org/job/Ambari-branch-2.5/201/]) AMBARI-18638. Include an option to upload query in hive-view (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=e93c13d0de512c1e9b33a224c5301700ed15ec83]) * (edit) contrib/views/hive-next/src/main/resources/ui/hive-web/app/controllers/index.js * (add) contrib/views/hive/src/main/resources/ui/hive-web/app/components/upload-query.js * (edit) contrib/views/hive/src/main/resources/ui/hive-web/app/templates/index.hbs * (edit) contrib/views/hive-next/src/main/resources/ui/hive-web/app/initializers/i18n.js * (edit) contrib/views/hive/src/main/resources/ui/hive-web/app/initializers/i18n.js * (edit) contrib/views/hive/src/main/resources/ui/hive-web/app/controllers/index.js * (add) contrib/views/hive-next/src/main/resources/ui/hive-web/app/components/upload-query.js * (edit) contrib/views/hive-next/src/main/resources/ui/hive-web/app/templates/index.hbs > Include an option to upload query in hive-view > -- > > Key: AMBARI-18638 > URL: https://issues.apache.org/jira/browse/AMBARI-18638 > Project: Ambari > Issue Type: Improvement > Components: ambari-views >Affects Versions: 2.5.0 >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: 2.5.0 > > Attachments: AMBARI-18638.patch, screenshot1.jpg, screenshot2.jpg > > > An option to upload the hive query into the worksheet from the UI can be > included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18693) get_sysprep_skip_copy_tarballs_hdfs() always returns False
[
https://issues.apache.org/jira/browse/AMBARI-18693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doroszlai, Attila updated AMBARI-18693:
---
Attachment: AMBARI-18693.patch
> get_sysprep_skip_copy_tarballs_hdfs() always returns False
> --
>
> Key: AMBARI-18693
> URL: https://issues.apache.org/jira/browse/AMBARI-18693
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.5.0
>Reporter: Doroszlai, Attila
>Assignee: Doroszlai, Attila
> Fix For: 3.0.0, 2.5.0
>
> Attachments: AMBARI-18693.patch
>
>
> {{get_sysprep_skip_copy_tarballs_hdfs()}} in
> {{ambari-common/src/main/python/resource_management/libraries/functions/copy_tarball.py}}
> looks for {{cluster-env}} in the wrong place, hence always returns
> {{False}}. This causes all scripts that use this function to unnecessarily
> copy to HDFS files that are already present in sysprepped environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18693) get_sysprep_skip_copy_tarballs_hdfs() always returns False
Doroszlai, Attila created AMBARI-18693:
--
Summary: get_sysprep_skip_copy_tarballs_hdfs() always returns False
Key: AMBARI-18693
URL: https://issues.apache.org/jira/browse/AMBARI-18693
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.5.0
Reporter: Doroszlai, Attila
Assignee: Doroszlai, Attila
Fix For: 3.0.0, 2.5.0
{{get_sysprep_skip_copy_tarballs_hdfs()}} in
{{ambari-common/src/main/python/resource_management/libraries/functions/copy_tarball.py}}
looks for {{cluster-env}} in the wrong place, hence always returns {{False}}.
This causes all scripts that use this function to unnecessarily copy to HDFS
files that are already present in sysprepped environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-14160) Ambari Slider View should pick up multiple versions of the same app package
[ https://issues.apache.org/jira/browse/AMBARI-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-14160: Description: I was validating some fix for Slider hbase with Gour. A new Slider hbase app package was built and moved to under: /var/lib/ambari-server/resources/apps We tried naming the new app package ending with -ted.zip -999.zip After 'ambari-server restart', the new app package was not picked up by Ambari. Ambari Slider View should be able to accommodate more than one version of app package. was: I was validating some fix for Slider hbase with Gour. A new Slider hbase app package was built and moved to under: /var/lib/ambari-server/resources/apps We tried naming the new app package ending with -ted.zip -999.zip After 'ambari-server restart', the new app package was not picked up by Ambari. Ambari Slider View should be able to accommodate more than one version of app package. > Ambari Slider View should pick up multiple versions of the same app package > --- > > Key: AMBARI-14160 > URL: https://issues.apache.org/jira/browse/AMBARI-14160 > Project: Ambari > Issue Type: Improvement >Reporter: Ted Yu > > I was validating some fix for Slider hbase with Gour. > A new Slider hbase app package was built and moved to under: > /var/lib/ambari-server/resources/apps > We tried naming the new app package ending with -ted.zip -999.zip > After 'ambari-server restart', the new app package was not picked up by > Ambari. > Ambari Slider View should be able to accommodate more than one version of app > package. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-13671) Ambari should check for duplicate config values
[ https://issues.apache.org/jira/browse/AMBARI-13671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-13671: Description: Using /#/main/services/HBASE/configs, I was able to save duplicate values for hbase.coprocessor.region.classes : org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint Ambari should check for duplicate config values. was: Using /#/main/services/HBASE/configs, I was able to save duplicate values for hbase.coprocessor.region.classes : org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint Ambari should check for duplicate config values. > Ambari should check for duplicate config values > --- > > Key: AMBARI-13671 > URL: https://issues.apache.org/jira/browse/AMBARI-13671 > Project: Ambari > Issue Type: Bug >Reporter: Ted Yu > > Using /#/main/services/HBASE/configs, I was able to save duplicate values for > hbase.coprocessor.region.classes : > org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint,org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint > Ambari should check for duplicate config values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18691) Improve and Update Workflow designer to support coordinators and bundles and
[ https://issues.apache.org/jira/browse/AMBARI-18691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605991#comment-15605991 ] Belliraj HB commented on AMBARI-18691: -- Patch will be available in couple of days. > Improve and Update Workflow designer to support coordinators and bundles and > - > > Key: AMBARI-18691 > URL: https://issues.apache.org/jira/browse/AMBARI-18691 > Project: Ambari > Issue Type: Bug > Components: ambari-views >Affects Versions: 2.4.0 >Reporter: Venkat Ranganathan >Assignee: Belliraj HB > > AMBARI-17213 created a workflow designer contrib view. > We need to support some of the missing featues such as > * Coordinators > * Bundles > Also usabilitiy enhancements like > * multiple tabs > * undo/delete support > * copy/paste > * improved validations > * Fix JS6 lint issues > * Dag generation in the UI > * Use cytoscape for diagraming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMBARI-18638) Include an option to upload query in hive-view
[ https://issues.apache.org/jira/browse/AMBARI-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605950#comment-15605950 ] Anita Gnanamalar Jebaraj edited comment on AMBARI-18638 at 10/25/16 5:56 PM: - Hi [~aantonenko], can the patch be pushed to 2.5 as well? was (Author: anitajebaraj): Hi, can the patch be pushed to 2.5 as well? > Include an option to upload query in hive-view > -- > > Key: AMBARI-18638 > URL: https://issues.apache.org/jira/browse/AMBARI-18638 > Project: Ambari > Issue Type: Improvement > Components: ambari-views >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: 3.0.0 > > Attachments: AMBARI-18638.patch, screenshot1.jpg, screenshot2.jpg > > > An option to upload the hive query into the worksheet from the UI can be > included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18692) Exporting blueprint from kerberos enabled cluster, exports hardcoded values cluster name and realm in principal_name property
[ https://issues.apache.org/jira/browse/AMBARI-18692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-18692: --- Status: Patch Available (was: In Progress) > Exporting blueprint from kerberos enabled cluster, exports hardcoded values > cluster name and realm in principal_name property > - > > Key: AMBARI-18692 > URL: https://issues.apache.org/jira/browse/AMBARI-18692 > Project: Ambari > Issue Type: Bug > Components: ambari-server, blueprints >Affects Versions: 2.4.0 >Reporter: Amruta Borkar >Assignee: Amruta Borkar > Fix For: trunk > > Attachments: AMBARI-18692.patch > > > Export a blueprint from kerberos enabled cluster, principal_name properties > get exported which contain hardocded cluster name and realm. > Due to this service starts fail when created a cluster with different name. > Workaround, > Regenerate keytabs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18692) Exporting blueprint from kerberos enabled cluster, exports hardcoded values cluster name and realm in principal_name property
[ https://issues.apache.org/jira/browse/AMBARI-18692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-18692: --- Attachment: AMBARI-18692.patch > Exporting blueprint from kerberos enabled cluster, exports hardcoded values > cluster name and realm in principal_name property > - > > Key: AMBARI-18692 > URL: https://issues.apache.org/jira/browse/AMBARI-18692 > Project: Ambari > Issue Type: Bug > Components: ambari-server, blueprints >Affects Versions: 2.4.0 >Reporter: Amruta Borkar >Assignee: Amruta Borkar > Fix For: trunk > > Attachments: AMBARI-18692.patch > > > Export a blueprint from kerberos enabled cluster, principal_name properties > get exported which contain hardocded cluster name and realm. > Due to this service starts fail when created a cluster with different name. > Workaround, > Regenerate keytabs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18692) Exporting blueprint from kerberos enabled cluster, exports hardcoded values cluster name and realm in principal_name property
[ https://issues.apache.org/jira/browse/AMBARI-18692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amruta Borkar updated AMBARI-18692: --- Description: Export a blueprint from kerberos enabled cluster, principal_name properties get exported which contain hardocded cluster name and realm. Due to this service starts fail when created a cluster with different name. Workaround, Regenerate keytabs > Exporting blueprint from kerberos enabled cluster, exports hardcoded values > cluster name and realm in principal_name property > - > > Key: AMBARI-18692 > URL: https://issues.apache.org/jira/browse/AMBARI-18692 > Project: Ambari > Issue Type: Bug > Components: ambari-server, blueprints >Affects Versions: 2.4.0 >Reporter: Amruta Borkar >Assignee: Amruta Borkar > Fix For: trunk > > > Export a blueprint from kerberos enabled cluster, principal_name properties > get exported which contain hardocded cluster name and realm. > Due to this service starts fail when created a cluster with different name. > Workaround, > Regenerate keytabs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18692) Exporting blueprint from kerberos enabled cluster, exports hardcoded values cluster name and realm in principal_name property
Amruta Borkar created AMBARI-18692: -- Summary: Exporting blueprint from kerberos enabled cluster, exports hardcoded values cluster name and realm in principal_name property Key: AMBARI-18692 URL: https://issues.apache.org/jira/browse/AMBARI-18692 Project: Ambari Issue Type: Bug Components: ambari-server, blueprints Affects Versions: 2.4.0 Reporter: Amruta Borkar Assignee: Amruta Borkar Fix For: trunk -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-18638) Include an option to upload query in hive-view
[ https://issues.apache.org/jira/browse/AMBARI-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Gnanamalar Jebaraj reopened AMBARI-18638: --- > Include an option to upload query in hive-view > -- > > Key: AMBARI-18638 > URL: https://issues.apache.org/jira/browse/AMBARI-18638 > Project: Ambari > Issue Type: Improvement > Components: ambari-views >Affects Versions: trunk >Reporter: Anita Gnanamalar Jebaraj >Assignee: Anita Gnanamalar Jebaraj >Priority: Minor > Fix For: 3.0.0 > > Attachments: AMBARI-18638.patch, screenshot1.jpg, screenshot2.jpg > > > An option to upload the hive query into the worksheet from the UI can be > included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18664) While syncing with LDAP, username collisions should be handled based on configuration value
[
https://issues.apache.org/jira/browse/AMBARI-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605922#comment-15605922
]
Hudson commented on AMBARI-18664:
-
FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #200 (See
[https://builds.apache.org/job/Ambari-branch-2.5/200/])
AMBARI-18664. While syncing with LDAP, username collisions should be (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=7800c071774442598ae7c98b07b619160dd1de7b])
* (edit) ambari-server/src/main/python/ambari-server.py
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulatorTest.java
* (edit) ambari-server/src/test/python/TestAmbariServer.py
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/LdapSyncEventResourceProvider.java
* (edit) ambari-server/docs/configuration/index.md
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/LdapSyncEventEntity.java
* (edit) ambari-server/src/main/python/ambari_server/setupSecurity.py
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulator.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/security/ldap/LdapBatchDto.java
> While syncing with LDAP, username collisions should be handled based on
> configuration value
> ---
>
> Key: AMBARI-18664
> URL: https://issues.apache.org/jira/browse/AMBARI-18664
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.5.0
>
> Attachments: AMBARI-18664_branch-2.5_01.patch,
> AMBARI-18664_branch-2.5_02.patch, AMBARI-18664_branch-2.5_03.patch
>
>
> While syncing with LDAP, username collisions should be handled based on an
> LDAP sync configuration value.
> The configuration options should be to indicate the following behaviors
> * convert
> ** convert the existing (non-LDAP user) user to an LDAP user
> ** This is the existing behavior
> * skip
> ** skip or ignore the collision, leaving the existing user unchanged
> ** a new user record should not be created
> Note: Future behavior may be to cause the sync operation to fail, but that
> shouldn't be handed yet.
> This configuration value should be set when setting up LDAP sync properties
> via {{ambari-server setup-ldap}} and be enforced when processing the sync
> operation in methods like
> {{org.apache.ambari.server.controller.AmbariManagementControllerImpl#synchronizeLdapUsersAndGroups}}
> or {{org.apache.ambari.server.security.authorization.Users#processLdapSync}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18690) Zeppelin fails to start after deployment due to timing issue
Dhanya Balasundaran created AMBARI-18690:
Summary: Zeppelin fails to start after deployment due to timing
issue
Key: AMBARI-18690
URL: https://issues.apache.org/jira/browse/AMBARI-18690
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.2
Reporter: Dhanya Balasundaran
Fix For: 2.4.2
Start services after HDP deployment fails at Zeepelin start with the below error
{code}
raise Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
'cp -f /etc/zeppelin/conf/interpreter.json /tmp/tmpl95NaD' returned 1. cp:
cannot stat '/etc/zeppelin/conf/interpreter.json': No such file or directory",
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18689) Licence text near all checkboxes
[ https://issues.apache.org/jira/browse/AMBARI-18689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605870#comment-15605870 ] Hudson commented on AMBARI-18689: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5867 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5867/]) AMBARI-18689. Licence text near all checkboxes (alexantonenko) (hiveww: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=70d8da7cda11e625269793cd05145c5ca83fec31]) * (edit) ambari-web/app/templates/common/checkbox.hbs > Licence text near all checkboxes > > > Key: AMBARI-18689 > URL: https://issues.apache.org/jira/browse/AMBARI-18689 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18689.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
[ https://issues.apache.org/jira/browse/AMBARI-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605857#comment-15605857 ] Hudson commented on AMBARI-18637: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #199 (See [https://builds.apache.org/job/Ambari-branch-2.5/199/]) AMBARI-18637: Management pack purge option should warn user and ask for (jluniya: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=56a320dfcdeb0ed2e47e268948dc12c138720469]) * (add) ambari-server/src/test/java/org/apache/ambari/server/checks/MpackInstallCheckerTest.java * (add) ambari-server/src/main/java/org/apache/ambari/server/checks/MpackInstallChecker.java * (edit) ambari-server/src/test/python/TestMpacks.py * (edit) ambari-server/src/main/python/ambari_server/setupMpacks.py > Management pack purge option should warn user and ask for confirmation before > purging > - > > Key: AMBARI-18637 > URL: https://issues.apache.org/jira/browse/AMBARI-18637 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya > Fix For: 2.4.2 > > Attachments: AMBARI-18637.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMBARI-10023) Ambari framework to support adding any new hadoop compatible file system with ease
[ https://issues.apache.org/jira/browse/AMBARI-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vijay Srinivasaraghavan resolved AMBARI-10023. -- Resolution: Fixed > Ambari framework to support adding any new hadoop compatible file system with > ease > -- > > Key: AMBARI-10023 > URL: https://issues.apache.org/jira/browse/AMBARI-10023 > Project: Ambari > Issue Type: Epic > Components: ambari-server, ambari-web >Affects Versions: trunk >Reporter: Vijay Srinivasaraghavan >Assignee: Vijay Srinivasaraghavan > Attachments: HCFS-Integration-Design Draft 1.pdf, Service > Type-Reference Implementation-Patch.txt > > > 1) Align Ambari’s design with Hadoop’s design, supporting pluggable > filesystems. > 2) Eliminate GlusterFS as a special case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18664) While syncing with LDAP, username collisions should be handled based on configuration value
[
https://issues.apache.org/jira/browse/AMBARI-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18664:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed to trunk
{noformat}
commit b67d8832108cf5874bddf1a6ccc186fa5ca69e85
Author: Robert Levas
Date: Tue Oct 25 11:59:15 2016 -0400
{noformat}
Committed to branch-2.5
{noformat}
commit 7800c071774442598ae7c98b07b619160dd1de7b
Author: Robert Levas
Date: Tue Oct 25 12:33:59 2016 -0400
{noformat}
> While syncing with LDAP, username collisions should be handled based on
> configuration value
> ---
>
> Key: AMBARI-18664
> URL: https://issues.apache.org/jira/browse/AMBARI-18664
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.5.0
>
> Attachments: AMBARI-18664_branch-2.5_01.patch,
> AMBARI-18664_branch-2.5_02.patch, AMBARI-18664_branch-2.5_03.patch
>
>
> While syncing with LDAP, username collisions should be handled based on an
> LDAP sync configuration value.
> The configuration options should be to indicate the following behaviors
> * convert
> ** convert the existing (non-LDAP user) user to an LDAP user
> ** This is the existing behavior
> * skip
> ** skip or ignore the collision, leaving the existing user unchanged
> ** a new user record should not be created
> Note: Future behavior may be to cause the sync operation to fail, but that
> shouldn't be handed yet.
> This configuration value should be set when setting up LDAP sync properties
> via {{ambari-server setup-ldap}} and be enforced when processing the sync
> operation in methods like
> {{org.apache.ambari.server.controller.AmbariManagementControllerImpl#synchronizeLdapUsersAndGroups}}
> or {{org.apache.ambari.server.security.authorization.Users#processLdapSync}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18664) While syncing with LDAP, username collisions should be handled based on configuration value
[
https://issues.apache.org/jira/browse/AMBARI-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18664:
--
Attachment: (was: AMBARI-18664_branch-2.4_02.patch)
> While syncing with LDAP, username collisions should be handled based on
> configuration value
> ---
>
> Key: AMBARI-18664
> URL: https://issues.apache.org/jira/browse/AMBARI-18664
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.5.0
>
> Attachments: AMBARI-18664_branch-2.5_01.patch,
> AMBARI-18664_branch-2.5_02.patch, AMBARI-18664_branch-2.5_03.patch
>
>
> While syncing with LDAP, username collisions should be handled based on an
> LDAP sync configuration value.
> The configuration options should be to indicate the following behaviors
> * convert
> ** convert the existing (non-LDAP user) user to an LDAP user
> ** This is the existing behavior
> * skip
> ** skip or ignore the collision, leaving the existing user unchanged
> ** a new user record should not be created
> Note: Future behavior may be to cause the sync operation to fail, but that
> shouldn't be handed yet.
> This configuration value should be set when setting up LDAP sync properties
> via {{ambari-server setup-ldap}} and be enforced when processing the sync
> operation in methods like
> {{org.apache.ambari.server.controller.AmbariManagementControllerImpl#synchronizeLdapUsersAndGroups}}
> or {{org.apache.ambari.server.security.authorization.Users#processLdapSync}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18664) While syncing with LDAP, username collisions should be handled based on configuration value
[
https://issues.apache.org/jira/browse/AMBARI-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18664:
--
Fix Version/s: (was: 2.4.2)
2.5.0
> While syncing with LDAP, username collisions should be handled based on
> configuration value
> ---
>
> Key: AMBARI-18664
> URL: https://issues.apache.org/jira/browse/AMBARI-18664
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.5.0
>
> Attachments: AMBARI-18664_branch-2.4_02.patch,
> AMBARI-18664_branch-2.5_01.patch, AMBARI-18664_branch-2.5_02.patch,
> AMBARI-18664_branch-2.5_03.patch
>
>
> While syncing with LDAP, username collisions should be handled based on an
> LDAP sync configuration value.
> The configuration options should be to indicate the following behaviors
> * convert
> ** convert the existing (non-LDAP user) user to an LDAP user
> ** This is the existing behavior
> * skip
> ** skip or ignore the collision, leaving the existing user unchanged
> ** a new user record should not be created
> Note: Future behavior may be to cause the sync operation to fail, but that
> shouldn't be handed yet.
> This configuration value should be set when setting up LDAP sync properties
> via {{ambari-server setup-ldap}} and be enforced when processing the sync
> operation in methods like
> {{org.apache.ambari.server.controller.AmbariManagementControllerImpl#synchronizeLdapUsersAndGroups}}
> or {{org.apache.ambari.server.security.authorization.Users#processLdapSync}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18664) While syncing with LDAP, username collisions should be handled based on configuration value
[
https://issues.apache.org/jira/browse/AMBARI-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Levas updated AMBARI-18664:
--
Attachment: (was: AMBARI-18664_branch-2.4_01.patch)
> While syncing with LDAP, username collisions should be handled based on
> configuration value
> ---
>
> Key: AMBARI-18664
> URL: https://issues.apache.org/jira/browse/AMBARI-18664
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.5.0
>
> Attachments: AMBARI-18664_branch-2.4_02.patch,
> AMBARI-18664_branch-2.5_01.patch, AMBARI-18664_branch-2.5_02.patch,
> AMBARI-18664_branch-2.5_03.patch
>
>
> While syncing with LDAP, username collisions should be handled based on an
> LDAP sync configuration value.
> The configuration options should be to indicate the following behaviors
> * convert
> ** convert the existing (non-LDAP user) user to an LDAP user
> ** This is the existing behavior
> * skip
> ** skip or ignore the collision, leaving the existing user unchanged
> ** a new user record should not be created
> Note: Future behavior may be to cause the sync operation to fail, but that
> shouldn't be handed yet.
> This configuration value should be set when setting up LDAP sync properties
> via {{ambari-server setup-ldap}} and be enforced when processing the sync
> operation in methods like
> {{org.apache.ambari.server.controller.AmbariManagementControllerImpl#synchronizeLdapUsersAndGroups}}
> or {{org.apache.ambari.server.security.authorization.Users#processLdapSync}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18684) Webhcat server start failed during EU with BindException
[
https://issues.apache.org/jira/browse/AMBARI-18684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605782#comment-15605782
]
Hudson commented on AMBARI-18684:
-
ABORTED: Integrated in Jenkins build Ambari-branch-2.5 #198 (See
[https://builds.apache.org/job/Ambari-branch-2.5/198/])
AMBARI-18684 - Webhcat server start failed during EU with BindException
(jhurley:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=0117dc3ae9dd2313124bc2dcace4ce7e559916e7])
* (edit) ambari-server/src/test/python/stacks/2.0.6/HIVE/test_webhcat_server.py
* (edit)
ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py
> Webhcat server start failed during EU with BindException
>
>
> Key: AMBARI-18684
> URL: https://issues.apache.org/jira/browse/AMBARI-18684
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18684.patch
>
>
> WebHCat may fail to restart during an upgrade due to the following exception:
> {code}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py",
> line 155, in
> WebHCatServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 219, in execute
> method(env)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 530, in restart
> self.start(env, upgrade_type=upgrade_type)
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py",
> line 42, in start
> webhcat_service(action='start', upgrade_type=upgrade_type)
> File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py",
> line 89, in thunk
> return fn(*args, **kwargs)
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py",
> line 54, in webhcat_service
> environment = environ)
> File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
> line 154, in __init__
> self.env.run()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
> line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 70, in inner
> result = function(command, **kwargs)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 291, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'cd /var/run/webhcat ;
> /usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh start' returned 1.
> {code}
> {noformat}
> WARN | 17 Oct 2016 12:53:02,999 |
> org.eclipse.jetty.util.component.AbstractLifeCycle | FAILED
> org.eclipse.jetty.server.Server@19a639d8: java.net.BindException: Address
> already in use
> java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:444)
> at sun.nio.ch.Net.bind(Net.java:436)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
> {noformat}
> The problem seems to be caused by the failure of WebHCat to stop before being
> upgraded. There was code added in AMBARI-12695 to address the issues with
> WebHCat not stopping, however, it doesn't look correct.
> - Return Code 0 (prevents the kill -9 from running due to {{not_if}}
> --
> {code}
> ! (ls /var/run/webhcat/webhcat.pid >/dev/null 2>&1 && ps -p
> `/var/lib/ambari-agent/ambari-sudo.sh su hcat -l -s /bin/bash -c 'cat
> /var/run/webhcat/webhcat.pid'` >/dev/null 2>&1) || ( sleep 10 && ! (ls
> /var/run/webhcat/webhcat.pid >/dev/null 2>&1 && ps -p `ambari-sudo.sh su hcat
> -l -s /bin/bash -c 'cat /var/run/webhcat/webhcat.pid'` >/dev/null 2>&1) )
> {code}
> - Return Code 0 (prevents Fail from being raised)
> --
> {code}
> ! (ls /var/run/webhcat/webhcat.pid >/dev/null 2>&1 && ps
[jira] [Commented] (AMBARI-18664) While syncing with LDAP, username collisions should be handled based on configuration value
[
https://issues.apache.org/jira/browse/AMBARI-18664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605778#comment-15605778
]
Hudson commented on AMBARI-18664:
-
FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5866 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/5866/])
AMBARI-18664. While syncing with LDAP, username collisions should be (rlevas:
[http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=b67d8832108cf5874bddf1a6ccc186fa5ca69e85])
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulator.java
* (edit) ambari-server/src/main/python/ambari_server/setupSecurity.py
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/security/ldap/LdapBatchDto.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/security/ldap/AmbariLdapDataPopulatorTest.java
* (edit) ambari-server/docs/configuration/index.md
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/LdapSyncEventResourceProvider.java
* (edit) ambari-server/src/main/python/ambari-server.py
* (edit) ambari-server/src/test/python/TestAmbariServer.py
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/orm/entities/LdapSyncEventEntity.java
> While syncing with LDAP, username collisions should be handled based on
> configuration value
> ---
>
> Key: AMBARI-18664
> URL: https://issues.apache.org/jira/browse/AMBARI-18664
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.0.0
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.4.2
>
> Attachments: AMBARI-18664_branch-2.4_01.patch,
> AMBARI-18664_branch-2.4_02.patch, AMBARI-18664_branch-2.5_01.patch,
> AMBARI-18664_branch-2.5_02.patch, AMBARI-18664_branch-2.5_03.patch
>
>
> While syncing with LDAP, username collisions should be handled based on an
> LDAP sync configuration value.
> The configuration options should be to indicate the following behaviors
> * convert
> ** convert the existing (non-LDAP user) user to an LDAP user
> ** This is the existing behavior
> * skip
> ** skip or ignore the collision, leaving the existing user unchanged
> ** a new user record should not be created
> Note: Future behavior may be to cause the sync operation to fail, but that
> shouldn't be handed yet.
> This configuration value should be set when setting up LDAP sync properties
> via {{ambari-server setup-ldap}} and be enforced when processing the sync
> operation in methods like
> {{org.apache.ambari.server.controller.AmbariManagementControllerImpl#synchronizeLdapUsersAndGroups}}
> or {{org.apache.ambari.server.security.authorization.Users#processLdapSync}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18689) Licence text near all checkboxes
[ https://issues.apache.org/jira/browse/AMBARI-18689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18689: - Resolution: Fixed Status: Resolved (was: Patch Available) committed to trunk > Licence text near all checkboxes > > > Key: AMBARI-18689 > URL: https://issues.apache.org/jira/browse/AMBARI-18689 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18689.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18689) Licence text near all checkboxes
[
https://issues.apache.org/jira/browse/AMBARI-18689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605768#comment-15605768
]
Hadoop QA commented on AMBARI-18689:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12835155/AMBARI-18689.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-web.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/9000//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/9000//console
This message is automatically generated.
> Licence text near all checkboxes
>
>
> Key: AMBARI-18689
> URL: https://issues.apache.org/jira/browse/AMBARI-18689
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 3.0.0
>Reporter: Antonenko Alexander
>Assignee: Antonenko Alexander
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: AMBARI-18689.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-18689) Licence text near all checkboxes
Antonenko Alexander created AMBARI-18689: Summary: Licence text near all checkboxes Key: AMBARI-18689 URL: https://issues.apache.org/jira/browse/AMBARI-18689 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 3.0.0 Reporter: Antonenko Alexander Assignee: Antonenko Alexander Priority: Critical Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18689) Licence text near all checkboxes
[ https://issues.apache.org/jira/browse/AMBARI-18689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605710#comment-15605710 ] Aleksandr Kovalenko commented on AMBARI-18689: -- +1 for the patch > Licence text near all checkboxes > > > Key: AMBARI-18689 > URL: https://issues.apache.org/jira/browse/AMBARI-18689 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 3.0.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander >Priority: Critical > Fix For: 3.0.0 > > Attachments: AMBARI-18689.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-16278) Give more time for HBase system tables to be assigned
[ https://issues.apache.org/jira/browse/AMBARI-16278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-16278: Description: We have observed extended cluster downtime due to HBase system tables not being assigned at cluster start up. The default values for the following two parameters are too low: hbase.regionserver.executor.openregion.threads (default: 3) hbase.master.namespace.init.timeout (default: 30) We set hbase.regionserver.executor.openregion.threads=200 and hbase.master.namespace.init.timeout=240 in some case to work around HBASE-14190. Ambari can use 20 for hbase.regionserver.executor.openregion.threads and 240 for hbase.master.namespace.init.timeout as default value. was: We have observed extended cluster downtime due to HBase system tables not being assigned at cluster start up. The default values for the following two parameters are too low: hbase.regionserver.executor.openregion.threads (default: 3) hbase.master.namespace.init.timeout (default: 30) We set hbase.regionserver.executor.openregion.threads=200 and hbase.master.namespace.init.timeout=240 in some case to work around HBASE-14190. Ambari can use 20 for hbase.regionserver.executor.openregion.threads and 240 for hbase.master.namespace.init.timeout as default value. > Give more time for HBase system tables to be assigned > - > > Key: AMBARI-16278 > URL: https://issues.apache.org/jira/browse/AMBARI-16278 > Project: Ambari > Issue Type: Improvement >Reporter: Ted Yu > > We have observed extended cluster downtime due to HBase system tables not > being assigned at cluster start up. > The default values for the following two parameters are too low: > hbase.regionserver.executor.openregion.threads (default: 3) > hbase.master.namespace.init.timeout (default: 30) > We set hbase.regionserver.executor.openregion.threads=200 and > hbase.master.namespace.init.timeout=240 in some case to work around > HBASE-14190. > Ambari can use 20 for hbase.regionserver.executor.openregion.threads and > 240 for hbase.master.namespace.init.timeout as default value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-14163) zookeeper session timeout for hbase should take zookeeper tickTime into account
[ https://issues.apache.org/jira/browse/AMBARI-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated AMBARI-14163: Description: With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value of 1 min 40 seconds. The change was accepted. However, such timeout is not reachable (it is > 20 times tickTime) Ambari should detect such scenario and warn user. was: With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value of 1 min 40 seconds. The change was accepted. However, such timeout is not reachable (it is > 20 times tickTime) Ambari should detect such scenario and warn user. > zookeeper session timeout for hbase should take zookeeper tickTime into > account > --- > > Key: AMBARI-14163 > URL: https://issues.apache.org/jira/browse/AMBARI-14163 > Project: Ambari > Issue Type: Bug >Reporter: Ted Yu > > With tickTime=2000 in zoo.cfg, I tried to set zookeeper.session.timeout value > of 1 min 40 seconds. > The change was accepted. > However, such timeout is not reachable (it is > 20 times tickTime) > Ambari should detect such scenario and warn user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18688) Kerberos wizard step2 page does not load properly
[
https://issues.apache.org/jira/browse/AMBARI-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605518#comment-15605518
]
Hadoop QA commented on AMBARI-18688:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12835118/AMBARI-18688_branch-2.4-maint.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8999//console
This message is automatically generated.
> Kerberos wizard step2 page does not load properly
> -
>
> Key: AMBARI-18688
> URL: https://issues.apache.org/jira/browse/AMBARI-18688
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18688_branch-2.4-maint.patch
>
>
> *Steps*
> # Install Ambari-2.4.2.0-47 build and deploy HDP-2.5.0.0 cluster
> # Open 'Enable Kerberos' wizard and navigate to step 2
> *Result*
> The screen does not show all the fields
> Ambari server logs indicate below:
> {code}
> 24 Oct 2016 06:06:33,919 INFO [ambari-client-thread-27]
> StackAdvisorRunner:47 -
> Script=/var/lib/ambari-server/resources/scripts/stack_advisor.py,
> actionDirectory=/var/run/ambari-server/stack-recommendations/7,
> command=recommend-configurations
> 24 Oct 2016 06:06:33,925 INFO [ambari-client-thread-27]
> StackAdvisorRunner:61 - Stack-advisor
> output=/var/run/ambari-server/stack-recommendations/7/stackadvisor.out,
> error=/var/run/ambari-server/stack-recommendations/7/stackadvisor.err
> 24 Oct 2016 06:06:34,583 INFO [ambari-client-thread-27]
> StackAdvisorRunner:69 - Stack advisor output files
> 24 Oct 2016 06:06:34,584 INFO [ambari-client-thread-27]
> StackAdvisorRunner:70 - advisor script stdout: StackAdvisor
> implementation for stack HDP, version 2.0.6 was loaded
> StackAdvisor implementation for stack HDP, version 2.1 was loaded
> StackAdvisor implementation for stack HDP, version 2.2 was loaded
> StackAdvisor implementation for stack HDP, version 2.3 was loaded
> StackAdvisor implementation for stack HDP, version 2.4 was loaded
> StackAdvisor implementation for stack HDP, version 2.5 was loaded
> Returning HDP25StackAdvisor implementation
> max_inmemory_regions: -0.45
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/AMBARI_METRICS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/FLUME.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HBASE.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HDFS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HOST.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/KAFKA.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/STORM.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/YARN.txt
> metrics length: 289
> ServiceAdvisor implementation for service SMARTSENSE was loaded
> 2016-10-24 06:06:34,547 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,548 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,550 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,550 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,551 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - No oozie configurations available
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
>
[jira] [Commented] (AMBARI-18671) Ranger KMS should add proxy users for yarn and livy
[
https://issues.apache.org/jira/browse/AMBARI-18671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605513#comment-15605513
]
Hadoop QA commented on AMBARI-18671:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12835122/AMBARI-18671.1-trunk.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
ambari-server.
Test results:
https://builds.apache.org/job/Ambari-trunk-test-patch/8998//testReport/
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/8998//console
This message is automatically generated.
> Ranger KMS should add proxy users for yarn and livy
> ---
>
> Key: AMBARI-18671
> URL: https://issues.apache.org/jira/browse/AMBARI-18671
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1, 2.4.2
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18671.1-trunk.patch, AMBARI-18671.1.patch,
> AMBARI-18671.patch
>
>
> Add below properties under kms-site.xml, if {{YARN|SPARK}} services are
> installed
> {noformat}
> hadoop.kms.proxyuser.[livy|yarn].groups=*
> hadoop.kms.proxyuser.[livy|yarn].hosts=*
> hadoop.kms.proxyuser.[livy|yarn].users=*
> {noformat}
> Also with above changes need to revert changes done for AMBARI-18096
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18627: - Resolution: Fixed Status: Resolved (was: Patch Available) committed to 2.4 > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.4.2 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch, > AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605481#comment-15605481 ] Antonenko Alexander commented on AMBARI-18627: -- rat check successful UI tests passed > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.4.2 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch, > AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18627: - Affects Version/s: (was: 2.5.0) 2.4.2 > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.4.2 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch, > AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18627: - Attachment: AMBARI-18627.patch > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.4.2 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.4.2 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch, > AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander updated AMBARI-18627: - Fix Version/s: (was: 2.5.0) 2.4.2 Status: Patch Available (was: Reopened) > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.4.2 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch, > AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMBARI-18627) Add service wizard hung at Choose services page as no ClusterStackVersion is available with state=CURRENT
[ https://issues.apache.org/jira/browse/AMBARI-18627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antonenko Alexander reopened AMBARI-18627: -- reopening to backport this to branch 2.4 > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT > - > > Key: AMBARI-18627 > URL: https://issues.apache.org/jira/browse/AMBARI-18627 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.5.0 >Reporter: Antonenko Alexander >Assignee: Antonenko Alexander > Fix For: 2.5.0 > > Attachments: AMBARI-18627.patch, AMBARI-18627.patch > > > Add service wizard hung at Choose services page as no ClusterStackVersion is > available with state=CURRENT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17956) ambari launches multiple server instances
[ https://issues.apache.org/jira/browse/AMBARI-17956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ellis Tite updated AMBARI-17956: Affects Version/s: (was: 2.2.2) 2.4.2 > ambari launches multiple server instances > - > > Key: AMBARI-17956 > URL: https://issues.apache.org/jira/browse/AMBARI-17956 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.2 > Environment: Centos 6 > HDP 2.4 >Reporter: Ellis Tite >Priority: Critical > > Something is repeatedly calling ambari-server start, we are having to close > multiple instances of ambari-server with different pid's and it is preventing > us seeing new stacks until we get them all. Checking in the pid file when > this happens there are often 2 pid's in there. This doesn't occur with > previous versions of ambari. > Sometimes, killing the processes with the pid's in the pid file and then > spamming "ambari-server stop" manages to kill the instances and get us back > to normality, other times we've been forced to add "exit 1" to > /etc/init.d/ambari-server and then kill all the ambari service processes. > This happens very regularly: we tend to add a stack, restart ambari, then > when we try to add another stack and restart ambari-server again we hit this > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18671) Ranger KMS should add proxy users for yarn and livy
[
https://issues.apache.org/jira/browse/AMBARI-18671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mugdha Varadkar updated AMBARI-18671:
-
Status: Patch Available (was: In Progress)
> Ranger KMS should add proxy users for yarn and livy
> ---
>
> Key: AMBARI-18671
> URL: https://issues.apache.org/jira/browse/AMBARI-18671
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1, 2.4.2
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18671.1-trunk.patch, AMBARI-18671.1.patch,
> AMBARI-18671.patch
>
>
> Add below properties under kms-site.xml, if {{YARN|SPARK}} services are
> installed
> {noformat}
> hadoop.kms.proxyuser.[livy|yarn].groups=*
> hadoop.kms.proxyuser.[livy|yarn].hosts=*
> hadoop.kms.proxyuser.[livy|yarn].users=*
> {noformat}
> Also with above changes need to revert changes done for AMBARI-18096
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18671) Ranger KMS should add proxy users for yarn and livy
[
https://issues.apache.org/jira/browse/AMBARI-18671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mugdha Varadkar updated AMBARI-18671:
-
Attachment: AMBARI-18671.1-trunk.patch
> Ranger KMS should add proxy users for yarn and livy
> ---
>
> Key: AMBARI-18671
> URL: https://issues.apache.org/jira/browse/AMBARI-18671
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1, 2.4.2
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18671.1-trunk.patch, AMBARI-18671.1.patch,
> AMBARI-18671.patch
>
>
> Add below properties under kms-site.xml, if {{YARN|SPARK}} services are
> installed
> {noformat}
> hadoop.kms.proxyuser.[livy|yarn].groups=*
> hadoop.kms.proxyuser.[livy|yarn].hosts=*
> hadoop.kms.proxyuser.[livy|yarn].users=*
> {noformat}
> Also with above changes need to revert changes done for AMBARI-18096
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18688) Kerberos wizard step2 page does not load properly
[
https://issues.apache.org/jira/browse/AMBARI-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605406#comment-15605406
]
Andrii Babiichuk commented on AMBARI-18688:
---
Committed to branch 2.4-maint
> Kerberos wizard step2 page does not load properly
> -
>
> Key: AMBARI-18688
> URL: https://issues.apache.org/jira/browse/AMBARI-18688
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18688_branch-2.4-maint.patch
>
>
> *Steps*
> # Install Ambari-2.4.2.0-47 build and deploy HDP-2.5.0.0 cluster
> # Open 'Enable Kerberos' wizard and navigate to step 2
> *Result*
> The screen does not show all the fields
> Ambari server logs indicate below:
> {code}
> 24 Oct 2016 06:06:33,919 INFO [ambari-client-thread-27]
> StackAdvisorRunner:47 -
> Script=/var/lib/ambari-server/resources/scripts/stack_advisor.py,
> actionDirectory=/var/run/ambari-server/stack-recommendations/7,
> command=recommend-configurations
> 24 Oct 2016 06:06:33,925 INFO [ambari-client-thread-27]
> StackAdvisorRunner:61 - Stack-advisor
> output=/var/run/ambari-server/stack-recommendations/7/stackadvisor.out,
> error=/var/run/ambari-server/stack-recommendations/7/stackadvisor.err
> 24 Oct 2016 06:06:34,583 INFO [ambari-client-thread-27]
> StackAdvisorRunner:69 - Stack advisor output files
> 24 Oct 2016 06:06:34,584 INFO [ambari-client-thread-27]
> StackAdvisorRunner:70 - advisor script stdout: StackAdvisor
> implementation for stack HDP, version 2.0.6 was loaded
> StackAdvisor implementation for stack HDP, version 2.1 was loaded
> StackAdvisor implementation for stack HDP, version 2.2 was loaded
> StackAdvisor implementation for stack HDP, version 2.3 was loaded
> StackAdvisor implementation for stack HDP, version 2.4 was loaded
> StackAdvisor implementation for stack HDP, version 2.5 was loaded
> Returning HDP25StackAdvisor implementation
> max_inmemory_regions: -0.45
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/AMBARI_METRICS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/FLUME.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HBASE.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HDFS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HOST.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/KAFKA.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/STORM.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/YARN.txt
> metrics length: 289
> ServiceAdvisor implementation for service SMARTSENSE was loaded
> 2016-10-24 06:06:34,547 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,548 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,550 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,550 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,551 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - No oozie configurations available
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,554 - Couldn't retrieve 'capacity-scheduler'
[jira] [Updated] (AMBARI-18671) Ranger KMS should add proxy users for yarn and livy
[
https://issues.apache.org/jira/browse/AMBARI-18671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mugdha Varadkar updated AMBARI-18671:
-
Attachment: AMBARI-18671.1.patch
> Ranger KMS should add proxy users for yarn and livy
> ---
>
> Key: AMBARI-18671
> URL: https://issues.apache.org/jira/browse/AMBARI-18671
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1, 2.4.2
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18671.1.patch, AMBARI-18671.patch
>
>
> Add below properties under kms-site.xml, if {{YARN|SPARK}} services are
> installed
> {noformat}
> hadoop.kms.proxyuser.[livy|yarn].groups=*
> hadoop.kms.proxyuser.[livy|yarn].hosts=*
> hadoop.kms.proxyuser.[livy|yarn].users=*
> {noformat}
> Also with above changes need to revert changes done for AMBARI-18096
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-18671) Ranger KMS should add proxy users for yarn and livy
[
https://issues.apache.org/jira/browse/AMBARI-18671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mugdha Varadkar updated AMBARI-18671:
-
Status: In Progress (was: Patch Available)
> Ranger KMS should add proxy users for yarn and livy
> ---
>
> Key: AMBARI-18671
> URL: https://issues.apache.org/jira/browse/AMBARI-18671
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0, 2.4.1, 2.4.2
>Reporter: Mugdha Varadkar
>Assignee: Mugdha Varadkar
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18671.patch
>
>
> Add below properties under kms-site.xml, if {{YARN|SPARK}} services are
> installed
> {noformat}
> hadoop.kms.proxyuser.[livy|yarn].groups=*
> hadoop.kms.proxyuser.[livy|yarn].hosts=*
> hadoop.kms.proxyuser.[livy|yarn].users=*
> {noformat}
> Also with above changes need to revert changes done for AMBARI-18096
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-18688) Kerberos wizard step2 page does not load properly
[
https://issues.apache.org/jira/browse/AMBARI-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605397#comment-15605397
]
Oleg Nechiporenko commented on AMBARI-18688:
+1 for patch
> Kerberos wizard step2 page does not load properly
> -
>
> Key: AMBARI-18688
> URL: https://issues.apache.org/jira/browse/AMBARI-18688
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18688_branch-2.4-maint.patch
>
>
> *Steps*
> # Install Ambari-2.4.2.0-47 build and deploy HDP-2.5.0.0 cluster
> # Open 'Enable Kerberos' wizard and navigate to step 2
> *Result*
> The screen does not show all the fields
> Ambari server logs indicate below:
> {code}
> 24 Oct 2016 06:06:33,919 INFO [ambari-client-thread-27]
> StackAdvisorRunner:47 -
> Script=/var/lib/ambari-server/resources/scripts/stack_advisor.py,
> actionDirectory=/var/run/ambari-server/stack-recommendations/7,
> command=recommend-configurations
> 24 Oct 2016 06:06:33,925 INFO [ambari-client-thread-27]
> StackAdvisorRunner:61 - Stack-advisor
> output=/var/run/ambari-server/stack-recommendations/7/stackadvisor.out,
> error=/var/run/ambari-server/stack-recommendations/7/stackadvisor.err
> 24 Oct 2016 06:06:34,583 INFO [ambari-client-thread-27]
> StackAdvisorRunner:69 - Stack advisor output files
> 24 Oct 2016 06:06:34,584 INFO [ambari-client-thread-27]
> StackAdvisorRunner:70 - advisor script stdout: StackAdvisor
> implementation for stack HDP, version 2.0.6 was loaded
> StackAdvisor implementation for stack HDP, version 2.1 was loaded
> StackAdvisor implementation for stack HDP, version 2.2 was loaded
> StackAdvisor implementation for stack HDP, version 2.3 was loaded
> StackAdvisor implementation for stack HDP, version 2.4 was loaded
> StackAdvisor implementation for stack HDP, version 2.5 was loaded
> Returning HDP25StackAdvisor implementation
> max_inmemory_regions: -0.45
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/AMBARI_METRICS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/FLUME.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HBASE.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HDFS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HOST.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/KAFKA.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/STORM.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/YARN.txt
> metrics length: 289
> ServiceAdvisor implementation for service SMARTSENSE was loaded
> 2016-10-24 06:06:34,547 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,548 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,550 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,550 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,551 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - No oozie configurations available
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,554 - Couldn't retrieve 'capacity-scheduler' from
>
[jira] [Updated] (AMBARI-18688) Kerberos wizard step2 page does not load properly
[
https://issues.apache.org/jira/browse/AMBARI-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrii Babiichuk updated AMBARI-18688:
--
Attachment: AMBARI-18688_branch-2.4-maint.patch
> Kerberos wizard step2 page does not load properly
> -
>
> Key: AMBARI-18688
> URL: https://issues.apache.org/jira/browse/AMBARI-18688
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18688_branch-2.4-maint.patch
>
>
> *Steps*
> # Install Ambari-2.4.2.0-47 build and deploy HDP-2.5.0.0 cluster
> # Open 'Enable Kerberos' wizard and navigate to step 2
> *Result*
> The screen does not show all the fields
> Ambari server logs indicate below:
> {code}
> 24 Oct 2016 06:06:33,919 INFO [ambari-client-thread-27]
> StackAdvisorRunner:47 -
> Script=/var/lib/ambari-server/resources/scripts/stack_advisor.py,
> actionDirectory=/var/run/ambari-server/stack-recommendations/7,
> command=recommend-configurations
> 24 Oct 2016 06:06:33,925 INFO [ambari-client-thread-27]
> StackAdvisorRunner:61 - Stack-advisor
> output=/var/run/ambari-server/stack-recommendations/7/stackadvisor.out,
> error=/var/run/ambari-server/stack-recommendations/7/stackadvisor.err
> 24 Oct 2016 06:06:34,583 INFO [ambari-client-thread-27]
> StackAdvisorRunner:69 - Stack advisor output files
> 24 Oct 2016 06:06:34,584 INFO [ambari-client-thread-27]
> StackAdvisorRunner:70 - advisor script stdout: StackAdvisor
> implementation for stack HDP, version 2.0.6 was loaded
> StackAdvisor implementation for stack HDP, version 2.1 was loaded
> StackAdvisor implementation for stack HDP, version 2.2 was loaded
> StackAdvisor implementation for stack HDP, version 2.3 was loaded
> StackAdvisor implementation for stack HDP, version 2.4 was loaded
> StackAdvisor implementation for stack HDP, version 2.5 was loaded
> Returning HDP25StackAdvisor implementation
> max_inmemory_regions: -0.45
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/AMBARI_METRICS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/FLUME.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HBASE.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HDFS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HOST.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/KAFKA.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/STORM.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/YARN.txt
> metrics length: 289
> ServiceAdvisor implementation for service SMARTSENSE was loaded
> 2016-10-24 06:06:34,547 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,548 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,550 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,550 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,551 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - No oozie configurations available
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,554 - Couldn't retrieve 'capacity-scheduler' from
> services.
>
[jira] [Updated] (AMBARI-18688) Kerberos wizard step2 page does not load properly
[
https://issues.apache.org/jira/browse/AMBARI-18688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrii Babiichuk updated AMBARI-18688:
--
Status: Patch Available (was: Open)
> Kerberos wizard step2 page does not load properly
> -
>
> Key: AMBARI-18688
> URL: https://issues.apache.org/jira/browse/AMBARI-18688
> Project: Ambari
> Issue Type: Bug
> Components: ambari-web
>Affects Versions: 2.4.2
>Reporter: Andrii Babiichuk
>Assignee: Andrii Babiichuk
>Priority: Blocker
> Fix For: 2.4.2
>
> Attachments: AMBARI-18688_branch-2.4-maint.patch
>
>
> *Steps*
> # Install Ambari-2.4.2.0-47 build and deploy HDP-2.5.0.0 cluster
> # Open 'Enable Kerberos' wizard and navigate to step 2
> *Result*
> The screen does not show all the fields
> Ambari server logs indicate below:
> {code}
> 24 Oct 2016 06:06:33,919 INFO [ambari-client-thread-27]
> StackAdvisorRunner:47 -
> Script=/var/lib/ambari-server/resources/scripts/stack_advisor.py,
> actionDirectory=/var/run/ambari-server/stack-recommendations/7,
> command=recommend-configurations
> 24 Oct 2016 06:06:33,925 INFO [ambari-client-thread-27]
> StackAdvisorRunner:61 - Stack-advisor
> output=/var/run/ambari-server/stack-recommendations/7/stackadvisor.out,
> error=/var/run/ambari-server/stack-recommendations/7/stackadvisor.err
> 24 Oct 2016 06:06:34,583 INFO [ambari-client-thread-27]
> StackAdvisorRunner:69 - Stack advisor output files
> 24 Oct 2016 06:06:34,584 INFO [ambari-client-thread-27]
> StackAdvisorRunner:70 - advisor script stdout: StackAdvisor
> implementation for stack HDP, version 2.0.6 was loaded
> StackAdvisor implementation for stack HDP, version 2.1 was loaded
> StackAdvisor implementation for stack HDP, version 2.2 was loaded
> StackAdvisor implementation for stack HDP, version 2.3 was loaded
> StackAdvisor implementation for stack HDP, version 2.4 was loaded
> StackAdvisor implementation for stack HDP, version 2.5 was loaded
> Returning HDP25StackAdvisor implementation
> max_inmemory_regions: -0.45
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/AMBARI_METRICS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/FLUME.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HBASE.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HDFS.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HOST.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/KAFKA.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/STORM.txt
> Processing file:
> /var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/YARN.txt
> metrics length: 289
> ServiceAdvisor implementation for service SMARTSENSE was loaded
> 2016-10-24 06:06:34,547 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,548 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,550 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,550 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,551 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,551 - No oozie configurations available
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as
> dictionary : 'True'. configs : []
> 2016-10-24 06:06:34,554 - Couldn't retrieve 'capacity-scheduler' from
> services.
> 2016-10-24
[jira] [Commented] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
[ https://issues.apache.org/jira/browse/AMBARI-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605388#comment-15605388 ] Hudson commented on AMBARI-18637: - FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #5865 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5865/]) AMBARI-18637: Management pack purge option should warn user and ask for (jluniya: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=8eead14916ddd86658c488dd07f9432dadcc2331]) * (add) ambari-server/src/main/java/org/apache/ambari/server/checks/MpackInstallChecker.java * (add) ambari-server/src/test/java/org/apache/ambari/server/checks/MpackInstallCheckerTest.java * (edit) ambari-server/src/test/python/TestMpacks.py * (edit) ambari-server/src/main/python/ambari_server/setupMpacks.py > Management pack purge option should warn user and ask for confirmation before > purging > - > > Key: AMBARI-18637 > URL: https://issues.apache.org/jira/browse/AMBARI-18637 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya > Fix For: 2.4.2 > > Attachments: AMBARI-18637.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-18688) Kerberos wizard step2 page does not load properly
Andrii Babiichuk created AMBARI-18688:
-
Summary: Kerberos wizard step2 page does not load properly
Key: AMBARI-18688
URL: https://issues.apache.org/jira/browse/AMBARI-18688
Project: Ambari
Issue Type: Bug
Components: ambari-web
Affects Versions: 2.4.2
Reporter: Andrii Babiichuk
Assignee: Andrii Babiichuk
Priority: Blocker
Fix For: 2.4.2
*Steps*
# Install Ambari-2.4.2.0-47 build and deploy HDP-2.5.0.0 cluster
# Open 'Enable Kerberos' wizard and navigate to step 2
*Result*
The screen does not show all the fields
Ambari server logs indicate below:
{code}
24 Oct 2016 06:06:33,919 INFO [ambari-client-thread-27] StackAdvisorRunner:47
- Script=/var/lib/ambari-server/resources/scripts/stack_advisor.py,
actionDirectory=/var/run/ambari-server/stack-recommendations/7,
command=recommend-configurations
24 Oct 2016 06:06:33,925 INFO [ambari-client-thread-27] StackAdvisorRunner:61
- Stack-advisor
output=/var/run/ambari-server/stack-recommendations/7/stackadvisor.out,
error=/var/run/ambari-server/stack-recommendations/7/stackadvisor.err
24 Oct 2016 06:06:34,583 INFO [ambari-client-thread-27] StackAdvisorRunner:69
- Stack advisor output files
24 Oct 2016 06:06:34,584 INFO [ambari-client-thread-27] StackAdvisorRunner:70
- advisor script stdout: StackAdvisor implementation for stack HDP, version
2.0.6 was loaded
StackAdvisor implementation for stack HDP, version 2.1 was loaded
StackAdvisor implementation for stack HDP, version 2.2 was loaded
StackAdvisor implementation for stack HDP, version 2.3 was loaded
StackAdvisor implementation for stack HDP, version 2.4 was loaded
StackAdvisor implementation for stack HDP, version 2.5 was loaded
Returning HDP25StackAdvisor implementation
max_inmemory_regions: -0.45
Processing file:
/var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/AMBARI_METRICS.txt
Processing file:
/var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/FLUME.txt
Processing file:
/var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HBASE.txt
Processing file:
/var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HDFS.txt
Processing file:
/var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/HOST.txt
Processing file:
/var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/KAFKA.txt
Processing file:
/var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/STORM.txt
Processing file:
/var/lib/ambari-server/resources/stacks/HDP/2.5/services/../../../../common-services/AMBARI_METRICS/0.1.0/package/files/service-metrics/YARN.txt
metrics length: 289
ServiceAdvisor implementation for service SMARTSENSE was loaded
2016-10-24 06:06:34,547 - Couldn't retrieve 'capacity-scheduler' from services.
2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as dictionary
: 'True'. configs : []
2016-10-24 06:06:34,548 - Couldn't retrieve 'capacity-scheduler' from services.
2016-10-24 06:06:34,548 - Retrieved 'capacity-scheduler' received as dictionary
: 'True'. configs : []
2016-10-24 06:06:34,550 - Couldn't retrieve 'capacity-scheduler' from services.
2016-10-24 06:06:34,550 - Retrieved 'capacity-scheduler' received as dictionary
: 'True'. configs : []
2016-10-24 06:06:34,551 - Couldn't retrieve 'capacity-scheduler' from services.
2016-10-24 06:06:34,551 - Retrieved 'capacity-scheduler' received as dictionary
: 'True'. configs : []
2016-10-24 06:06:34,551 - No oozie configurations available
2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from services.
2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as dictionary
: 'True'. configs : []
2016-10-24 06:06:34,552 - Couldn't retrieve 'capacity-scheduler' from services.
2016-10-24 06:06:34,552 - Retrieved 'capacity-scheduler' received as dictionary
: 'True'. configs : []
2016-10-24 06:06:34,554 - Couldn't retrieve 'capacity-scheduler' from services.
2016-10-24 06:06:34,554 - Retrieved 'capacity-scheduler' received as dictionary
: 'True'. configs : []
24 Oct 2016 06:06:34,584 INFO [ambari-client-thread-27] StackAdvisorRunner:71
- advisor script stderr: 2016-10-24 06:06:34,547 - Couldn't retrieve
'capacity-scheduler' from services.
2016-10-24 06:06:34,548 - Couldn't retrieve 'capacity-scheduler' from services.
2016-10-24 06:06:34,550 - Couldn't retrieve 'capacity-scheduler'
[jira] [Updated] (AMBARI-18637) Management pack purge option should warn user and ask for confirmation before purging
[ https://issues.apache.org/jira/browse/AMBARI-18637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayush Luniya updated AMBARI-18637: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Management pack purge option should warn user and ask for confirmation before > purging > - > > Key: AMBARI-18637 > URL: https://issues.apache.org/jira/browse/AMBARI-18637 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Jayush Luniya >Assignee: Jayush Luniya > Fix For: 2.4.2 > > Attachments: AMBARI-18637.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-14384) Ambari Metrics doesn't use SPNEGO to authenticate
[ https://issues.apache.org/jira/browse/AMBARI-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605226#comment-15605226 ] Hudson commented on AMBARI-14384: - SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #5863 (See [https://builds.apache.org/job/Ambari-trunk-Commit/5863/]) Revert "AMBARI-14384 Ambari Metrics doesn't use SPNEGO to authenticate (dsen: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=32b28120dbca718e1a5b17c12b27c24eee321a45]) * (edit) ambari-metrics/ambari-metrics-common/src/test/java/org/apache/hadoop/metrics2/sink/timeline/availability/MetricCollectorHATest.java * (edit) ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java * (edit) ambari-metrics/ambari-metrics-common/pom.xml > Ambari Metrics doesn't use SPNEGO to authenticate > - > > Key: AMBARI-14384 > URL: https://issues.apache.org/jira/browse/AMBARI-14384 > Project: Ambari > Issue Type: Improvement > Components: ambari-metrics >Affects Versions: 2.1.2 >Reporter: Ward Viaene >Assignee: Dmytro Sen > Fix For: 2.5.0 > > Attachments: AMBARI-14384_2.patch > > > * Kerberos enabled cluster > * SPNEGO enabled on hadoop APIs > /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out: > 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: > http://metrics-collector:6188/ws/v1/timeline/metrics > 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to > server. HTTP Error 401: Authentication required > 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ... > The same problem appears to be happening on the sinks: > * > ambari/ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java > ** No SPNEGO support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-14384) Ambari Metrics doesn't use SPNEGO to authenticate
[ https://issues.apache.org/jira/browse/AMBARI-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605195#comment-15605195 ] Hudson commented on AMBARI-14384: - FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #197 (See [https://builds.apache.org/job/Ambari-branch-2.5/197/]) Revert "AMBARI-14384 Ambari Metrics doesn't use SPNEGO to authenticate (dsen: [http://git-wip-us.apache.org/repos/asf?p=ambari.git=commit=7c734dbade4b37536947db0e9893fd949d049ae9]) * (edit) ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java * (edit) ambari-metrics/ambari-metrics-common/pom.xml * (edit) ambari-server/src/main/resources/common-services/HDFS/2.1.0.2.0/configuration/hadoop-metrics2.properties.xml > Ambari Metrics doesn't use SPNEGO to authenticate > - > > Key: AMBARI-14384 > URL: https://issues.apache.org/jira/browse/AMBARI-14384 > Project: Ambari > Issue Type: Improvement > Components: ambari-metrics >Affects Versions: 2.1.2 >Reporter: Ward Viaene >Assignee: Dmytro Sen > Fix For: 2.5.0 > > Attachments: AMBARI-14384_2.patch > > > * Kerberos enabled cluster > * SPNEGO enabled on hadoop APIs > /var/log/ambari-metrics-monitor/ambari-metrics-monitor.out: > 2015-12-15 13:26:30,663 [INFO] emitter.py:101 - server: > http://metrics-collector:6188/ws/v1/timeline/metrics > 2015-12-15 13:26:30,671 [WARNING] emitter.py:84 - Error sending metrics to > server. HTTP Error 401: Authentication required > 2015-12-15 13:26:30,671 [WARNING] emitter.py:90 - Retrying after 5 ... > The same problem appears to be happening on the sinks: > * > ambari/ambari-metrics/ambari-metrics-common/src/main/java/org/apache/hadoop/metrics2/sink/timeline/AbstractTimelineMetricsSink.java > ** No SPNEGO support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-18684) Webhcat server start failed during EU with BindException
[
https://issues.apache.org/jira/browse/AMBARI-18684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hurley updated AMBARI-18684:
-
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Webhcat server start failed during EU with BindException
>
>
> Key: AMBARI-18684
> URL: https://issues.apache.org/jira/browse/AMBARI-18684
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.0
>Reporter: Jonathan Hurley
>Assignee: Jonathan Hurley
>Priority: Blocker
> Fix For: 2.5.0
>
> Attachments: AMBARI-18684.patch
>
>
> WebHCat may fail to restart during an upgrade due to the following exception:
> {code}
> Traceback (most recent call last):
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py",
> line 155, in
> WebHCatServer().execute()
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 219, in execute
> method(env)
> File
> "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
> line 530, in restart
> self.start(env, upgrade_type=upgrade_type)
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py",
> line 42, in start
> webhcat_service(action='start', upgrade_type=upgrade_type)
> File "/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py",
> line 89, in thunk
> return fn(*args, **kwargs)
> File
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py",
> line 54, in webhcat_service
> environment = environ)
> File "/usr/lib/python2.6/site-packages/resource_management/core/base.py",
> line 154, in __init__
> self.env.run()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 160, in run
> self.run_action(resource, action)
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/environment.py",
> line 124, in run_action
> provider_action()
> File
> "/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py",
> line 238, in action_run
> tries=self.resource.tries, try_sleep=self.resource.try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 70, in inner
> result = function(command, **kwargs)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 92, in checked_call
> tries=tries, try_sleep=try_sleep)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 140, in _call_wrapper
> result = _call(command, **kwargs_copy)
> File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py",
> line 291, in _call
> raise Fail(err_msg)
> resource_management.core.exceptions.Fail: Execution of 'cd /var/run/webhcat ;
> /usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh start' returned 1.
> {code}
> {noformat}
> WARN | 17 Oct 2016 12:53:02,999 |
> org.eclipse.jetty.util.component.AbstractLifeCycle | FAILED
> org.eclipse.jetty.server.Server@19a639d8: java.net.BindException: Address
> already in use
> java.net.BindException: Address already in use
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:444)
> at sun.nio.ch.Net.bind(Net.java:436)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:214)
> {noformat}
> The problem seems to be caused by the failure of WebHCat to stop before being
> upgraded. There was code added in AMBARI-12695 to address the issues with
> WebHCat not stopping, however, it doesn't look correct.
> - Return Code 0 (prevents the kill -9 from running due to {{not_if}}
> --
> {code}
> ! (ls /var/run/webhcat/webhcat.pid >/dev/null 2>&1 && ps -p
> `/var/lib/ambari-agent/ambari-sudo.sh su hcat -l -s /bin/bash -c 'cat
> /var/run/webhcat/webhcat.pid'` >/dev/null 2>&1) || ( sleep 10 && ! (ls
> /var/run/webhcat/webhcat.pid >/dev/null 2>&1 && ps -p `ambari-sudo.sh su hcat
> -l -s /bin/bash -c 'cat /var/run/webhcat/webhcat.pid'` >/dev/null 2>&1) )
> {code}
> - Return Code 0 (prevents Fail from being raised)
> --
> {code}
> ! (ls /var/run/webhcat/webhcat.pid >/dev/null 2>&1 && ps -p
> `/var/lib/ambari-agent/ambari-sudo.sh su hcat -l -s /bin/bash -c 'cat
> /var/run/webhcat/webhcat.pid'` >/dev/null 2>&1)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
