[jira] [Created] (AMBARI-15336) Blueprints: NullPointerException when unncessary config types found with %HOSTGROUP% tags
Sebastian Toader created AMBARI-15336: - Summary: Blueprints: NullPointerException when unncessary config types found with %HOSTGROUP% tags Key: AMBARI-15336 URL: https://issues.apache.org/jira/browse/AMBARI-15336 Project: Ambari Issue Type: Bug Affects Versions: 2.2.1 Reporter: Sebastian Toader Assignee: Sebastian Toader Fix For: 2.4.0 NPE is thrown during cluster provisioning when the Blueprint contains configurations that are not used by any of the services that are listed in the Blueprint to be installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15336) Blueprints: NullPointerException when unncessary config types found with %HOSTGROUP% tags
[ https://issues.apache.org/jira/browse/AMBARI-15336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15336: -- Status: Patch Available (was: In Progress) > Blueprints: NullPointerException when unncessary config types found with > %HOSTGROUP% tags > - > > Key: AMBARI-15336 > URL: https://issues.apache.org/jira/browse/AMBARI-15336 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-15336.v1.patch > > > NPE is thrown during cluster provisioning when the Blueprint contains > configurations that are not used by any of the services that are listed in > the Blueprint to be installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15336) Blueprints: NullPointerException when unncessary config types found with %HOSTGROUP% tags
[ https://issues.apache.org/jira/browse/AMBARI-15336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15336: -- Attachment: AMBARI-15336.v1.patch > Blueprints: NullPointerException when unncessary config types found with > %HOSTGROUP% tags > - > > Key: AMBARI-15336 > URL: https://issues.apache.org/jira/browse/AMBARI-15336 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-15336.v1.patch > > > NPE is thrown during cluster provisioning when the Blueprint contains > configurations that are not used by any of the services that are listed in > the Blueprint to be installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15336) Blueprints: NullPointerException when unncessary config types found with %HOSTGROUP% tags
[ https://issues.apache.org/jira/browse/AMBARI-15336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15336: -- Attachment: (was: AMBARI-15336.v1.patch) > Blueprints: NullPointerException when unncessary config types found with > %HOSTGROUP% tags > - > > Key: AMBARI-15336 > URL: https://issues.apache.org/jira/browse/AMBARI-15336 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-15336.v2.patch > > > NPE is thrown during cluster provisioning when the Blueprint contains > configurations that are not used by any of the services that are listed in > the Blueprint to be installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15336) Blueprints: NullPointerException when unncessary config types found with %HOSTGROUP% tags
[ https://issues.apache.org/jira/browse/AMBARI-15336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15336: -- Attachment: AMBARI-15336.v2.patch > Blueprints: NullPointerException when unncessary config types found with > %HOSTGROUP% tags > - > > Key: AMBARI-15336 > URL: https://issues.apache.org/jira/browse/AMBARI-15336 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-15336.v2.patch > > > NPE is thrown during cluster provisioning when the Blueprint contains > configurations that are not used by any of the services that are listed in > the Blueprint to be installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15336) Blueprints: NullPointerException when unncessary config types found with %HOSTGROUP% tags
[ https://issues.apache.org/jira/browse/AMBARI-15336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15336: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Blueprints: NullPointerException when unncessary config types found with > %HOSTGROUP% tags > - > > Key: AMBARI-15336 > URL: https://issues.apache.org/jira/browse/AMBARI-15336 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader > Fix For: 2.4.0 > > Attachments: AMBARI-15336.v2.patch > > > NPE is thrown during cluster provisioning when the Blueprint contains > configurations that are not used by any of the services that are listed in > the Blueprint to be installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15296) Missing property: hive.server2.authentication.kerberos.keytab
[
https://issues.apache.org/jira/browse/AMBARI-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188906#comment-15188906
]
Sebastian Toader commented on AMBARI-15296:
---
Committed to branch-2.2:
{code}
commit ea069b334ae0b163c0670145c02f10e92d64d101
Author: Toader, Sebastian
Date: Wed Mar 9 20:41:07 2016 +0100
AMBARI-15296. Missing property:
hive.server2.authentication.kerberos.keytab. (Laszlo Puskas via stoader)
{code}
> Missing property: hive.server2.authentication.kerberos.keytab
> -
>
> Key: AMBARI-15296
> URL: https://issues.apache.org/jira/browse/AMBARI-15296
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Mahadev konar
>Assignee: Laszlo Puskas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15296.v1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15296) Missing property: hive.server2.authentication.kerberos.keytab
[ https://issues.apache.org/jira/browse/AMBARI-15296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15296: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Missing property: hive.server2.authentication.kerberos.keytab > - > > Key: AMBARI-15296 > URL: https://issues.apache.org/jira/browse/AMBARI-15296 > Project: Ambari > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Mahadev konar >Assignee: Laszlo Puskas > Fix For: 2.2.2 > > Attachments: AMBARI-15296.v1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15376) Fix typo in get_stack_version
[
https://issues.apache.org/jira/browse/AMBARI-15376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189876#comment-15189876
]
Sebastian Toader commented on AMBARI-15376:
---
+1
> Fix typo in get_stack_version
> -
>
> Key: AMBARI-15376
> URL: https://issues.apache.org/jira/browse/AMBARI-15376
> Project: Ambari
> Issue Type: Bug
> Components: ambari-agent
>Affects Versions: 2.4.0
>Reporter: Jayush Luniya
>Assignee: Jayush Luniya
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-15376.patch
>
>
> Fix a typo introduced in AMBARI-15329 which causes get_stack_version to
> report stack_version = None.
> 2016-03-10 18:57:13,534 - call['ambari-python-wrap /usr/bin/hdp-select status
> hadoop-client'] {'timeout': 20}
> 2016-03-10 18:57:13,610 - call returned (0, 'hadoop-client - 2.5.0.0-80')
> 2016-03-10 18:57:13,611 - Failed to get extracted version with
> /usr/bin/hdp-select
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15465) Increase Ambari Server Perm gen default value
[
https://issues.apache.org/jira/browse/AMBARI-15465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202589#comment-15202589
]
Sebastian Toader commented on AMBARI-15465:
---
Committed to trunk:
{noformat}
commit 74f31459800db97b5d355139eea7e79c47156c7b
Author: Toader, Sebastian
Date: Sat Mar 19 06:41:18 2016 +0100
AMBARI-15465. Increase Ambari Server Perm gen default value. (Daniel
Gergley via stoader)
{noformat}
> Increase Ambari Server Perm gen default value
> -
>
> Key: AMBARI-15465
> URL: https://issues.apache.org/jira/browse/AMBARI-15465
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-15465.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15457) Topology host info is not cleared when a host is removed
[
https://issues.apache.org/jira/browse/AMBARI-15457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202639#comment-15202639
]
Sebastian Toader commented on AMBARI-15457:
---
Committed to branch-2.2
{noformat}
commit 4ae09499732c9d997edbb215837713619dc4e639
Author: Toader, Sebastian
Date: Sat Mar 19 07:19:43 2016 +0100
AMBARI-15457. Topology host info is not cleared when a host is removed.
(Daniel Gergely via stoader)
{noformat}
> Topology host info is not cleared when a host is removed
>
>
> Key: AMBARI-15457
> URL: https://issues.apache.org/jira/browse/AMBARI-15457
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15457.patch, AMBARI-15457_branch-2.2.patch
>
>
> When a host is removed, a record is left in the topology_host_info table. As
> a result re-adding the same host is not possible, due to invalid topology.
> Host removal should remove the corresponding record from topology_host_info
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15457) Topology host info is not cleared when a host is removed
[
https://issues.apache.org/jira/browse/AMBARI-15457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202837#comment-15202837
]
Sebastian Toader commented on AMBARI-15457:
---
Committed to trunk:
{noformat}
commit a6dd447b0878029197f00b2f4cd34adba88e5d47
Author: Toader, Sebastian
Date: Sat Mar 19 11:52:51 2016 +0100
AMBARI-15457. Topology host info is not cleared when a host is removed.
(Daniel Gergely via stoader)
{noformat}
> Topology host info is not cleared when a host is removed
>
>
> Key: AMBARI-15457
> URL: https://issues.apache.org/jira/browse/AMBARI-15457
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15457.patch, AMBARI-15457_branch-2.2.patch
>
>
> When a host is removed, a record is left in the topology_host_info table. As
> a result re-adding the same host is not possible, due to invalid topology.
> Host removal should remove the corresponding record from topology_host_info
> as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15465) Increase Ambari Server Perm gen default value
[ https://issues.apache.org/jira/browse/AMBARI-15465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15465: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Increase Ambari Server Perm gen default value > - > > Key: AMBARI-15465 > URL: https://issues.apache.org/jira/browse/AMBARI-15465 > Project: Ambari > Issue Type: Improvement > Components: ambari-server >Reporter: Daniel Gergely >Assignee: Daniel Gergely > Fix For: 2.4.0 > > Attachments: AMBARI-15465.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15457) Topology host info is not cleared when a host is removed
[ https://issues.apache.org/jira/browse/AMBARI-15457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15457: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Topology host info is not cleared when a host is removed > > > Key: AMBARI-15457 > URL: https://issues.apache.org/jira/browse/AMBARI-15457 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Reporter: Daniel Gergely >Assignee: Daniel Gergely > Fix For: 2.4.0, 2.2.2 > > Attachments: AMBARI-15457.patch, AMBARI-15457_branch-2.2.patch > > > When a host is removed, a record is left in the topology_host_info table. As > a result re-adding the same host is not possible, due to invalid topology. > Host removal should remove the corresponding record from topology_host_info > as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
Sebastian Toader created AMBARI-15489:
-
Summary: Configuration with tag 'TOPOLOGY_RESOLVED' exists for
'cluster-env' error when creating Kerberized cluster with Blueprints
Key: AMBARI-15489
URL: https://issues.apache.org/jira/browse/AMBARI-15489
Project: Ambari
Issue Type: Bug
Affects Versions: 2.2.2
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Priority: Critical
Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when
creating Kerberized cluster with Blueprints.
{noformat}
17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
AmbariManagementControllerImpl:1471 - Applying configuration with tag
'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
TopologyManager.ConfigureClusterTask: An exception occurred while attempting to
process cluster configs and set on cluster:
java.lang.RuntimeException: Failed to set configurations on cluster:
org.apache.ambari.server.AmbariException: Configuration with tag
'TOPOLOGY_RESOLVED' exists for 'cluster-env'
at
org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
at
org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
at
org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
at
org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
at
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
at
org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
'TOPOLOGY_RESOLVED' exists for 'cluster-env'
at
org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
at
org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
... 11 more
Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
'TOPOLOGY_RESOLVED' exists for 'cluster-env'
at
org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
at
org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
at
org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
at
org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
at
org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
... 12 more
17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
Exception during task execution:
java.util.concurrent.ExecutionException: java.lang.Exception:
java.lang.RuntimeException: Failed to set configurations on cluster:
org.apache.ambari.server.AmbariException: Configuration with tag
'TOPOLOGY_RESOLVED' exists for 'cluste
r-env'
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:206)
at
org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
at
org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
at
org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.Exception: java.lang.RuntimeException: Failed to set
configurations on cluster: org.apache.ambari.server.AmbariException:
Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
at
org.apache.ambari.server.topology.TopologyManager$Co
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Fix Version/s: 2.2.2
2.4.0
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0, 2.2.2
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Th
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Fix Version/s: (was: 2.4.0)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runW
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Attachment: AMBARI-15489.v1.patch
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v1.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> a
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Status: Patch Available (was: In Progress)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v1.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Fix Version/s: 2.4.0
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15489.v1.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> j
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Fix Version/s: (was: 2.4.0)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v1.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Attachment: AMBARI-15489.v2.patch
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> a
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Attachment: (was: AMBARI-15489.v1.patch)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Attachment: AMBARI-15489-trunk.v2.patch
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489-trunk.v2.patch, AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.util.concurrent.FutureTask.r
[jira] [Commented] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205073#comment-15205073
]
Sebastian Toader commented on AMBARI-15489:
---
Committed to branch-2.2:
{code}
commit 4dfcaf8864b211fd8cbf1fc522f2b8fe0e8a3782
Author: Toader, Sebastian
Date: Mon Mar 21 19:23:53 2016 +0100
AMBARI-15489. Configuration with tag 'TOPOLOGY_RESOLVED' exists for
'cluster-env' error when creating Kerberized cluster with Blueprints. (stoader)
{code}
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489-trunk.v2.patch, AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.Asy
[jira] [Commented] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205284#comment-15205284
]
Sebastian Toader commented on AMBARI-15489:
---
Committed to trunk:
{code}
commit d2ccdcaa4435c15c6559c405383c12aac5ae
Author: Toader, Sebastian
Date: Mon Mar 21 19:23:53 2016 +0100
AMBARI-15489. Configuration with tag 'TOPOLOGY_RESOLVED' exists for
'cluster-env' error when creating Kerberized cluster with Blueprints. (stoader)
{code}
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489-trunk.v2.patch, AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncC
[jira] [Updated] (AMBARI-15489) Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error when creating Kerberized cluster with Blueprints
[
https://issues.apache.org/jira/browse/AMBARI-15489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15489:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints
> --
>
> Key: AMBARI-15489
> URL: https://issues.apache.org/jira/browse/AMBARI-15489
> Project: Ambari
> Issue Type: Bug
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15489-trunk.v2.patch, AMBARI-15489.v2.patch
>
>
> Configuration with tag 'TOPOLOGY_RESOLVED' exists for 'cluster-env' error
> when creating Kerberized cluster with Blueprints.
> {noformat}
> 17 Mar 2016 21:17:51,611 INFO [pool-9-thread-1]
> AmbariManagementControllerImpl:1471 - Applying configuration with tag
> 'TOPOLOGY_RESOLVED' to cluster 'c1' for configuration type cluster-env
> 17 Mar 2016 21:17:51,611 ERROR [pool-9-thread-1] TopologyManager:766 -
> TopologyManager.ConfigureClusterTask: An exception occurred while attempting
> to process cluster configs and set on cluster:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:390)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:416)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.setConfigurationsOnCluster(ClusterConfigurationRequest.java:336)
> at
> org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:145)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:764)
> at
> org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:738)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:110)
> at
> org.apache.ambari.server.topology.AmbariContext.setConfigurationOnCluster(AmbariContext.java:381)
> ... 11 more
> Caused by: org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluster-env'
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.createConfiguration(AmbariManagementControllerImpl.java:754)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateCluster(AmbariManagementControllerImpl.java:1477)
> at
> org.apache.ambari.server.controller.AmbariManagementControllerImpl.updateClusters(AmbariManagementControllerImpl.java:1337)
> at
> org.apache.ambari.server.topology.AmbariContext$5.call(AmbariContext.java:384)
> at
> org.apache.ambari.server.utils.RetryHelper.executeWithRetry(RetryHelper.java:95)
> ... 12 more
> 17 Mar 2016 21:17:51,611 INFO [pool-3-thread-1] AsyncCallableService:111 -
> Exception during task execution:
> java.util.concurrent.ExecutionException: java.lang.Exception:
> java.lang.RuntimeException: Failed to set configurations on cluster:
> org.apache.ambari.server.AmbariException: Configuration with tag
> 'TOPOLOGY_RESOLVED' exists for 'cluste
> r-env'
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.ambari.server.topology.AsyncCallableService.taskCompleted(AsyncCallableService.java:103)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:74)
> at
> org.apache.ambari.server.topology.AsyncCallableService.call(AsyncCallableService.java:37)
> at java.u
[jira] [Created] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
Sebastian Toader created AMBARI-15554:
-
Summary: Ambari LDAP integration cannot handle LDAP directories
with multiple entries for the same user
Key: AMBARI-15554
URL: https://issues.apache.org/jira/browse/AMBARI-15554
Project: Ambari
Issue Type: New Feature
Components: ambari-server, ambari-web
Affects Versions: 2.1.1
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Fix For: 2.4.0
*Problem:*
In case LDAP set up with multiple Domains which are joined into a Forrest with
trusts between the different Domains users may appear in different locations
in LDAP.
Since users who wants to access Ambari can be in any domain Ambari has to
search the whole forrest, and as the users appearing in multiple domains are
identical Ambari cannot filter out all but one of the user entries.
This leads to the following error message when they try to login to Ambari with
one of the users that has multiple entries:
{code}
ServletHandler:563 - /api/v1/users/USERNAME
org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
result size: expected 1, actual 2
at
org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
at
org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
at
org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
at
org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
at
org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
at
org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
at
org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
at
org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
at
org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
at
org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
at
org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
at
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
at
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
at
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
at
org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
at
org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Attachment: AMBARI-15554.v1.patch
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v1.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
> at
> org.ec
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Status: Patch Available (was: In Progress)
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v1.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
> at
[jira] [Updated] (AMBARI-15531) Hiveserver2 goes down on HA cluster deployed via blueprint
[
https://issues.apache.org/jira/browse/AMBARI-15531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15531:
--
Fix Version/s: 2.4.0
> Hiveserver2 goes down on HA cluster deployed via blueprint
> --
>
> Key: AMBARI-15531
> URL: https://issues.apache.org/jira/browse/AMBARI-15531
> Project: Ambari
> Issue Type: Bug
>Reporter: Laszlo Puskas
>Assignee: Laszlo Puskas
>Priority: Critical
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15531.b22.v1.patch, AMBARI-15531.b22.v2.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> On an HA cluster deployed via bluerint, HiveServer2 is down and we see below
> in hiveserver2 logs
> {code}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=hive, access=WRITE,
> inode="/tmp/hive":hdfs:hdfs:drwxr-xr-x
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1780)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1764)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1747)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:3930)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1068)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:622)
> at
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2206)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2202)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2200)
> at org.apache.hadoop.ipc.Client.call(Client.java:1427)
> at org.apache.hadoop.ipc.Client.call(Client.java:1358)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
> at com.sun.proxy.$Proxy15.mkdirs(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.mkdirs(ClientNamenodeProtocolTranslatorPB.java:558)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:252)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:104)
> at com.sun.proxy.$Proxy16.mkdirs(Unknown Source)
> at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:3018)
> ... 24 more
> 2016-03-21 20:06:00,216 INFO [Thread-4]: server.HiveServer2
> (HiveStringUtils.java:run(709)) - SHUTDOWN_MSG:
> /
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15531) Hiveserver2 goes down on HA cluster deployed via blueprint
[
https://issues.apache.org/jira/browse/AMBARI-15531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15211650#comment-15211650
]
Sebastian Toader commented on AMBARI-15531:
---
Committed to trunk:
{code}
commit 99ffb6eb55847652f4feddaedd18accf2c45f761
Author: Toader, Sebastian
Date: Fri Mar 25 06:24:59 2016 +0100
AMBARI-15531. Hiveserver2 goes down on HA cluster deployed via blueprint.
(Laszlo Puskas via stoader)
{code}
Committed to branch-2.2:
{code}
commit 1e8da1a5a3ba772ea8e660529576cf0ab3dac8d6
Author: Toader, Sebastian
Date: Fri Mar 25 06:24:59 2016 +0100
AMBARI-15531. Hiveserver2 goes down on HA cluster deployed via blueprint.
(Laszlo Puskas via stoader)
{code}
> Hiveserver2 goes down on HA cluster deployed via blueprint
> --
>
> Key: AMBARI-15531
> URL: https://issues.apache.org/jira/browse/AMBARI-15531
> Project: Ambari
> Issue Type: Bug
>Reporter: Laszlo Puskas
>Assignee: Laszlo Puskas
>Priority: Critical
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15531.b22.v1.patch, AMBARI-15531.b22.v2.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> On an HA cluster deployed via bluerint, HiveServer2 is down and we see below
> in hiveserver2 logs
> {code}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=hive, access=WRITE,
> inode="/tmp/hive":hdfs:hdfs:drwxr-xr-x
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1780)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1764)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1747)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:3930)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1068)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:622)
> at
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2206)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2202)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2200)
> at org.apache.hadoop.ipc.Client.call(Client.java:1427)
> at org.apache.hadoop.ipc.Client.call(Client.java:1358)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
> at com.sun.proxy.$Proxy15.mkdirs(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.mkdirs(ClientNamenodeProtocolTranslatorPB.java:558)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:252)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:104)
> at com.sun.proxy.$Proxy16.mkdirs(Unknown Source)
> at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:3018)
> ... 24 more
> 2016-03-21 20:06:00,216 INFO [Thread-4]: server.HiveServer2
> (HiveStringUtils.java:run(709)) - SHUTDOWN_MSG:
> /
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15531) Hiveserver2 goes down on HA cluster deployed via blueprint
[
https://issues.apache.org/jira/browse/AMBARI-15531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15531:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Hiveserver2 goes down on HA cluster deployed via blueprint
> --
>
> Key: AMBARI-15531
> URL: https://issues.apache.org/jira/browse/AMBARI-15531
> Project: Ambari
> Issue Type: Bug
>Reporter: Laszlo Puskas
>Assignee: Laszlo Puskas
>Priority: Critical
> Fix For: 2.4.0, 2.2.2
>
> Attachments: AMBARI-15531.b22.v1.patch, AMBARI-15531.b22.v2.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> On an HA cluster deployed via bluerint, HiveServer2 is down and we see below
> in hiveserver2 logs
> {code}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=hive, access=WRITE,
> inode="/tmp/hive":hdfs:hdfs:drwxr-xr-x
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:213)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1780)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1764)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkAncestorAccess(FSDirectory.java:1747)
> at
> org.apache.hadoop.hdfs.server.namenode.FSDirMkdirOp.mkdirs(FSDirMkdirOp.java:71)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.mkdirs(FSNamesystem.java:3930)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.mkdirs(NameNodeRpcServer.java:1068)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.mkdirs(ClientNamenodeProtocolServerSideTranslatorPB.java:622)
> at
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2206)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2202)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2200)
> at org.apache.hadoop.ipc.Client.call(Client.java:1427)
> at org.apache.hadoop.ipc.Client.call(Client.java:1358)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
> at com.sun.proxy.$Proxy15.mkdirs(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.mkdirs(ClientNamenodeProtocolTranslatorPB.java:558)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:252)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:104)
> at com.sun.proxy.$Proxy16.mkdirs(Unknown Source)
> at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:3018)
> ... 24 more
> 2016-03-21 20:06:00,216 INFO [Thread-4]: server.HiveServer2
> (HiveStringUtils.java:run(709)) - SHUTDOWN_MSG:
> /
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Attachment: AMBARI-15554.v2.patch
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v2.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
> at
> org.ec
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Attachment: (was: AMBARI-15554.v1.patch)
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v2.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
> a
[jira] [Commented] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15214632#comment-15214632
]
Sebastian Toader commented on AMBARI-15554:
---
Committed to trunk:
{code}
commit 71b4c624fb219bb1626c238322bda6c2e5589f72
Author: Toader, Sebastian
Date: Mon Mar 28 13:04:17 2016 +0200
AMBARI-15554. Ambari LDAP integration cannot handle LDAP directories with
multiple entries for the same user. (stoader)
{code}
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v2.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(
[jira] [Updated] (AMBARI-15554) Ambari LDAP integration cannot handle LDAP directories with multiple entries for the same user
[
https://issues.apache.org/jira/browse/AMBARI-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15554:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Ambari LDAP integration cannot handle LDAP directories with multiple entries
> for the same user
> --
>
> Key: AMBARI-15554
> URL: https://issues.apache.org/jira/browse/AMBARI-15554
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server, ambari-web
>Affects Versions: 2.1.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
> Fix For: 2.4.0
>
> Attachments: AMBARI-15554.v2.patch
>
>
> *Problem:*
> In case LDAP set up with multiple Domains which are joined into a Forrest
> with trusts between the different Domains users may appear in different
> locations in LDAP.
> Since users who wants to access Ambari can be in any domain Ambari has to
> search the whole forrest, and as the users appearing in multiple domains are
> identical Ambari cannot filter out all but one of the user entries.
> This leads to the following error message when they try to login to Ambari
> with one of the users that has multiple entries:
> {code}
> ServletHandler:563 - /api/v1/users/USERNAME
> org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect
> result size: expected 1, actual 2
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:243)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:198)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:807)
>
> at
> org.springframework.ldap.core.LdapTemplate.executeReadOnly(LdapTemplate.java:793)
>
> at
> org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntry(SpringSecurityLdapTemplate.java:196)
>
> at
> org.springframework.security.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:116)
>
> at
> org.springframework.security.ldap.authentication.BindAuthenticator.authenticate(BindAuthenticator.java:90)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapBindAuthenticator.authenticate(AmbariLdapBindAuthenticator.java:53)
>
> at
> org.springframework.security.ldap.authentication.LdapAuthenticationProvider.doAuthentication(LdapAuthenticationProvider.java:178)
>
> at
> org.springframework.security.ldap.authentication.AbstractLdapAuthenticationProvider.authenticate(AbstractLdapAuthenticationProvider.java:61)
>
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:60)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
>
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:174)
>
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
>
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
>
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
>
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
>
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:82)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:294)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(Servlet
[jira] [Updated] (AMBARI-15241) Basic Operational Audit Logging
[ https://issues.apache.org/jira/browse/AMBARI-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15241: -- Attachment: AMBARI-15241.v2.patch > Basic Operational Audit Logging > --- > > Key: AMBARI-15241 > URL: https://issues.apache.org/jira/browse/AMBARI-15241 > Project: Ambari > Issue Type: New Feature > Components: ambari-server >Reporter: Sebastian Toader >Assignee: Daniel Gergely >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-15241.patch, AMBARI-15241.v2.patch > > > Ambari should audit operational events (including user, timestamp, etc) such > as: start, stop, restart, move, add/delete service, add/delete component, > enable/disable kerberos, enter/leave maintenance mode, > create/edit/enable/disable alerts. This should also include user/group role > changes (including Ambari Admin flag). > This information should be available in an operational log. > When an operation is executed in Ambari, append an entry to a history log > showing: > The timestamp is when the operation is started > The user is the logged in user > The operation is what is currently displayed in the operations UI > The success/fail is what is displayed in the UI when the operation is > completed > Comment is an optional field the user can supply -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15241) Basic Operational Audit Logging
[
https://issues.apache.org/jira/browse/AMBARI-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218707#comment-15218707
]
Sebastian Toader commented on AMBARI-15241:
---
Committed to trunk:
{code}
commit 46a34ccdabe0ad4172e94a63c9b077e17861
Author: Toader, Sebastian
Date: Wed Mar 30 20:02:27 2016 +0200
AMBARI-15241. Basic Operational Audit Logging. (Daniel Gergely via stoader)
{code}
> Basic Operational Audit Logging
> ---
>
> Key: AMBARI-15241
> URL: https://issues.apache.org/jira/browse/AMBARI-15241
> Project: Ambari
> Issue Type: New Feature
> Components: ambari-server
>Reporter: Sebastian Toader
>Assignee: Daniel Gergely
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-15241.v2.patch
>
>
> Ambari should audit operational events (including user, timestamp, etc) such
> as: start, stop, restart, move, add/delete service, add/delete component,
> enable/disable kerberos, enter/leave maintenance mode,
> create/edit/enable/disable alerts. This should also include user/group role
> changes (including Ambari Admin flag).
> This information should be available in an operational log.
> When an operation is executed in Ambari, append an entry to a history log
> showing:
> The timestamp is when the operation is started
> The user is the logged in user
> The operation is what is currently displayed in the operations UI
> The success/fail is what is displayed in the UI when the operation is
> completed
> Comment is an optional field the user can supply
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15241) Basic Operational Audit Logging
[ https://issues.apache.org/jira/browse/AMBARI-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15241: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Basic Operational Audit Logging > --- > > Key: AMBARI-15241 > URL: https://issues.apache.org/jira/browse/AMBARI-15241 > Project: Ambari > Issue Type: New Feature > Components: ambari-server >Reporter: Sebastian Toader >Assignee: Daniel Gergely >Priority: Critical > Fix For: 2.4.0 > > Attachments: AMBARI-15241.v2.patch > > > Ambari should audit operational events (including user, timestamp, etc) such > as: start, stop, restart, move, add/delete service, add/delete component, > enable/disable kerberos, enter/leave maintenance mode, > create/edit/enable/disable alerts. This should also include user/group role > changes (including Ambari Admin flag). > This information should be available in an operational log. > When an operation is executed in Ambari, append an entry to a history log > showing: > The timestamp is when the operation is started > The user is the logged in user > The operation is what is currently displayed in the operations UI > The success/fail is what is displayed in the UI when the operation is > completed > Comment is an optional field the user can supply -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
Sebastian Toader created AMBARI-15643: - Summary: During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING. Key: AMBARI-15643 URL: https://issues.apache.org/jira/browse/AMBARI-15643 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.2.1 Reporter: Sebastian Toader Assignee: Sebastian Toader Priority: Critical Fix For: 2.2.2 After the cluster creation template posted to Ambari (via the REST Api) to provision a cluster using Blueprints is accepted for processing Ambari returns in the response the url of the request through which the status/progress of the cluster creation can be tracked. When querying the status of the request it erroneously returns "COMPLETED" instead of returning "PENDING" until the first task of the cluster creation is scheduled to be executed on one of the cluster nodes. Once at least one task is scheduled to be executed the status of the request should change to "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks completed succesfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
[ https://issues.apache.org/jira/browse/AMBARI-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15643: -- Attachment: AMBARI-15643.v1.patch > During cluster creation using Blueprints the cluster creation request has > incorrect COMPLETED state instead of PENDING. > --- > > Key: AMBARI-15643 > URL: https://issues.apache.org/jira/browse/AMBARI-15643 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-15643.v1.patch > > > After the cluster creation template posted to Ambari (via the REST Api) to > provision a cluster using Blueprints is accepted for processing Ambari > returns in the response the url of the request through which the > status/progress of the cluster creation can be tracked. > When querying the status of the request it erroneously returns "COMPLETED" > instead of returning "PENDING" until the first task of the cluster creation > is scheduled to be executed on one of the cluster nodes. Once at least one > task is scheduled to be executed the status of the request should change to > "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks > completed succesfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
[ https://issues.apache.org/jira/browse/AMBARI-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15643: -- Status: Patch Available (was: In Progress) > During cluster creation using Blueprints the cluster creation request has > incorrect COMPLETED state instead of PENDING. > --- > > Key: AMBARI-15643 > URL: https://issues.apache.org/jira/browse/AMBARI-15643 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-15643.v1.patch > > > After the cluster creation template posted to Ambari (via the REST Api) to > provision a cluster using Blueprints is accepted for processing Ambari > returns in the response the url of the request through which the > status/progress of the cluster creation can be tracked. > When querying the status of the request it erroneously returns "COMPLETED" > instead of returning "PENDING" until the first task of the cluster creation > is scheduled to be executed on one of the cluster nodes. Once at least one > task is scheduled to be executed the status of the request should change to > "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks > completed succesfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
[
https://issues.apache.org/jira/browse/AMBARI-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15220167#comment-15220167
]
Sebastian Toader commented on AMBARI-15643:
---
Committed to trunk:
{code}
commit 6f61de093943a75868925cb7f76cbceea6215ae9
Author: Toader, Sebastian
Date: Thu Mar 31 16:39:29 2016 +0200
AMBARI-15643. During cluster creation using Blueprints the cluster creation
request has incorrect COMPLETED state instead of PENDING. (stoader)
{code}
> During cluster creation using Blueprints the cluster creation request has
> incorrect COMPLETED state instead of PENDING.
> ---
>
> Key: AMBARI-15643
> URL: https://issues.apache.org/jira/browse/AMBARI-15643
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15643.v1.patch
>
>
> After the cluster creation template posted to Ambari (via the REST Api) to
> provision a cluster using Blueprints is accepted for processing Ambari
> returns in the response the url of the request through which the
> status/progress of the cluster creation can be tracked.
> When querying the status of the request it erroneously returns "COMPLETED"
> instead of returning "PENDING" until the first task of the cluster creation
> is scheduled to be executed on one of the cluster nodes. Once at least one
> task is scheduled to be executed the status of the request should change to
> "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks
> completed succesfully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
[
https://issues.apache.org/jira/browse/AMBARI-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15220169#comment-15220169
]
Sebastian Toader commented on AMBARI-15643:
---
Committed to branch-2.2:
{code}
commit 4268948058773a2800e37f25d3f87d40f053618b
Author: Toader, Sebastian
Date: Thu Mar 31 16:39:29 2016 +0200
AMBARI-15643. During cluster creation using Blueprints the cluster creation
request has incorrect COMPLETED state instead of PENDING. (stoader)
{code}
> During cluster creation using Blueprints the cluster creation request has
> incorrect COMPLETED state instead of PENDING.
> ---
>
> Key: AMBARI-15643
> URL: https://issues.apache.org/jira/browse/AMBARI-15643
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.1
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15643.v1.patch
>
>
> After the cluster creation template posted to Ambari (via the REST Api) to
> provision a cluster using Blueprints is accepted for processing Ambari
> returns in the response the url of the request through which the
> status/progress of the cluster creation can be tracked.
> When querying the status of the request it erroneously returns "COMPLETED"
> instead of returning "PENDING" until the first task of the cluster creation
> is scheduled to be executed on one of the cluster nodes. Once at least one
> task is scheduled to be executed the status of the request should change to
> "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks
> completed succesfully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15643) During cluster creation using Blueprints the cluster creation request has incorrect COMPLETED state instead of PENDING.
[ https://issues.apache.org/jira/browse/AMBARI-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15643: -- Resolution: Fixed Status: Resolved (was: Patch Available) > During cluster creation using Blueprints the cluster creation request has > incorrect COMPLETED state instead of PENDING. > --- > > Key: AMBARI-15643 > URL: https://issues.apache.org/jira/browse/AMBARI-15643 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.1 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Critical > Fix For: 2.2.2 > > Attachments: AMBARI-15643.v1.patch > > > After the cluster creation template posted to Ambari (via the REST Api) to > provision a cluster using Blueprints is accepted for processing Ambari > returns in the response the url of the request through which the > status/progress of the cluster creation can be tracked. > When querying the status of the request it erroneously returns "COMPLETED" > instead of returning "PENDING" until the first task of the cluster creation > is scheduled to be executed on one of the cluster nodes. Once at least one > task is scheduled to be executed the status of the request should change to > "IN_PROGRESS". The "COMPLETED" state should be reached when all tasks > completed succesfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15645) Upgrading Kerberized JournalNode requires HDFS principal to perform 'role edits' task
[
https://issues.apache.org/jira/browse/AMBARI-15645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221353#comment-15221353
]
Sebastian Toader commented on AMBARI-15645:
---
Committed to branch-2.2
{code}
commit 7a39a9905a170cea43dd550f2c034b3ed88bd5b1
Author: Robert Levas
Date: Fri Apr 1 10:09:18 2016 +0200
AMBARI-15645. Upgrading Kerberized JournalNode requires HDFS principal to
perform 'role edits' task. (Robert Levas via stoader)
{code}
Committed to trunk:
{code}
commit 0ada5769a54e687d54bbedd3011f456c6de4559e
Author: Robert Levas
Date: Fri Apr 1 10:09:18 2016 +0200
AMBARI-15645. Upgrading Kerberized JournalNode requires HDFS principal to
perform 'role edits' task. (Robert Levas via stoader)
{code}
> Upgrading Kerberized JournalNode requires HDFS principal to perform 'role
> edits' task
> -
>
> Key: AMBARI-15645
> URL: https://issues.apache.org/jira/browse/AMBARI-15645
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15645_branch-2.2_01.patch,
> AMBARI-15645_trunk_01.patch
>
>
> After upgrading HDP in Ambari version 2.1.2.1 a task a performed to _role
> edits_ while restarting JournalNodes. If Kerberos is enabled, the JN Kerberos
> identity is established before making this call when really the HDFS identity
> should be established - since this is an administrative HDFS call that
> requires the HDFS administrator user to perform.
> Because of this, the following error is generated and seen in the :
> {noformat}
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access
> denied for user jn. Superuser privilege is required
> {noformat}
> The offending code is
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
> if params.security_enabled:
> Execute(params.jn_kinit_cmd, user=params.hdfs_user)
> time.sleep(5)
> hdfs_roll_edits()
> time.sleep(5)
> {code}
> It should probably be something like:
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
> if params.security_enabled:
> Execute(params.hdfs_kinit_cmd, user=params.hdfs_user)
> time.sleep(5)
> hdfs_roll_edits()
> time.sleep(5)
> {code}
> *Note the change from jn to hdfs in the kinit command line.*
> This issue has also been posted in
> https://issues.apache.org/jira/browse/AMBARI-10519.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15645) Upgrading Kerberized JournalNode requires HDFS principal to perform 'role edits' task
[
https://issues.apache.org/jira/browse/AMBARI-15645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15645:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Upgrading Kerberized JournalNode requires HDFS principal to perform 'role
> edits' task
> -
>
> Key: AMBARI-15645
> URL: https://issues.apache.org/jira/browse/AMBARI-15645
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.1.2
>Reporter: Robert Levas
>Assignee: Robert Levas
> Fix For: 2.2.2
>
> Attachments: AMBARI-15645_branch-2.2_01.patch,
> AMBARI-15645_trunk_01.patch
>
>
> After upgrading HDP in Ambari version 2.1.2.1 a task a performed to _role
> edits_ while restarting JournalNodes. If Kerberos is enabled, the JN Kerberos
> identity is established before making this call when really the HDFS identity
> should be established - since this is an administrative HDFS call that
> requires the HDFS administrator user to perform.
> Because of this, the following error is generated and seen in the :
> {noformat}
> Fail: Execution of 'hdfs dfsadmin -rollEdits' returned 255. rollEdits: Access
> denied for user jn. Superuser privilege is required
> {noformat}
> The offending code is
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
> if params.security_enabled:
> Execute(params.jn_kinit_cmd, user=params.hdfs_user)
> time.sleep(5)
> hdfs_roll_edits()
> time.sleep(5)
> {code}
> It should probably be something like:
> {code:title=common-services/HDFS/2.1.0.2.0/package/scripts/journalnode_upgrade.py}
> if params.security_enabled:
> Execute(params.hdfs_kinit_cmd, user=params.hdfs_user)
> time.sleep(5)
> hdfs_roll_edits()
> time.sleep(5)
> {code}
> *Note the change from jn to hdfs in the kinit command line.*
> This issue has also been posted in
> https://issues.apache.org/jira/browse/AMBARI-10519.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15665) Unable to Create Cluster Fails Due To Audit Logger
[
https://issues.apache.org/jira/browse/AMBARI-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15223162#comment-15223162
]
Sebastian Toader commented on AMBARI-15665:
---
Committed to trunk:
{code}
commit 836647a36966b1b534e1419b30d4b31858773478
Author: Daniel Gergely
Date: Sat Apr 2 11:29:37 2016 +0200
AMBARI-15665. Unable to Create Cluster Fails Due To Audit Logger. (Daniel
Gergley via stoader)
{code}
> Unable to Create Cluster Fails Due To Audit Logger
> --
>
> Key: AMBARI-15665
> URL: https://issues.apache.org/jira/browse/AMBARI-15665
> Project: Ambari
> Issue Type: Bug
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
>Priority: Blocker
> Attachments: AMBARI-15665.patch
>
>
> Attempt to update repository information in preparation for a new cluster
> creation:
> {code}
> PUT
> api/v1/stacks/HDP/versions/2.3/operating_systems/redhat6/repositories/HDP-2.3
> {
> "Repositories": {
> "base_url": "http://repo.ambari.apache.org/hdp/centos6/HDP-2.3.6.0-3566/";,
> "verify_base_url": true
> }
> }
> {code}
> {code}
> 2016-03-31 15:47:17,822 WARN [qtp-ambari-client-35]
> (ServletHandler.java:628) doHandle() -
> /api/v1/stacks/HDP/versions/2.3/operating_systems/redhat6/repositories/HDP-2.3
> java.lang.ClassCastException:
> org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter$1
> cannot be cast to org.springframework.security.core.userdetails.User
> at
> org.apache.ambari.server.audit.request.eventcreator.RepositoryEventCreator.createAuditEvent(RepositoryEventCreator.java:83)
> at
> org.apache.ambari.server.audit.request.RequestAuditLoggerImpl.log(RequestAuditLoggerImpl.java:85)
> at
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:130)
> at
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:83)
> at
> org.apache.ambari.server.api.services.RepositoryService.updateRepository(RepositoryService.java:145)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15665) Unable to Create Cluster Fails Due To Audit Logger
[
https://issues.apache.org/jira/browse/AMBARI-15665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15665:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Unable to Create Cluster Fails Due To Audit Logger
> --
>
> Key: AMBARI-15665
> URL: https://issues.apache.org/jira/browse/AMBARI-15665
> Project: Ambari
> Issue Type: Bug
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
>Priority: Blocker
> Attachments: AMBARI-15665.patch
>
>
> Attempt to update repository information in preparation for a new cluster
> creation:
> {code}
> PUT
> api/v1/stacks/HDP/versions/2.3/operating_systems/redhat6/repositories/HDP-2.3
> {
> "Repositories": {
> "base_url": "http://repo.ambari.apache.org/hdp/centos6/HDP-2.3.6.0-3566/";,
> "verify_base_url": true
> }
> }
> {code}
> {code}
> 2016-03-31 15:47:17,822 WARN [qtp-ambari-client-35]
> (ServletHandler.java:628) doHandle() -
> /api/v1/stacks/HDP/versions/2.3/operating_systems/redhat6/repositories/HDP-2.3
> java.lang.ClassCastException:
> org.apache.ambari.server.security.authorization.AmbariAuthorizationFilter$1
> cannot be cast to org.springframework.security.core.userdetails.User
> at
> org.apache.ambari.server.audit.request.eventcreator.RepositoryEventCreator.createAuditEvent(RepositoryEventCreator.java:83)
> at
> org.apache.ambari.server.audit.request.RequestAuditLoggerImpl.log(RequestAuditLoggerImpl.java:85)
> at
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:130)
> at
> org.apache.ambari.server.api.services.BaseService.handleRequest(BaseService.java:83)
> at
> org.apache.ambari.server.api.services.RepositoryService.updateRepository(RepositoryService.java:145)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
Sebastian Toader created AMBARI-15744:
-
Summary: Webhcat Server failed to stop while stopping all the
services
Key: AMBARI-15744
URL: https://issues.apache.org/jira/browse/AMBARI-15744
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.2.2
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Priority: Critical
Fix For: 2.2.2
Stop all the services using Stop All on dashboard. Webhcat server fails to stop
with the below error. This looks like an intermittent issue.
{code}
"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
line 155, in \nWebHCatServer().execute()\n File
\"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
line 219, in execute\nmethod(env)\n File
\"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
line 47, in stop\nwebhcat_service(action='stop')\n File
\"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
line 89, in thunk\nreturn fn(*args, **kwargs)\n File
\"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
line 57, in webhcat_service\nenvironment = environ)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
line 154, in __init__\nself.env.run()\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
line 158, in run\nself.run_action(resource, action)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
line 121, in run_action\nprovider_action()\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
line 238, in action_run\ntries=self.resource.tries,
try_sleep=self.resource.try_sleep)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
line 70, in inner\nresult = function(command, **kwargs)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n File
\"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
line 140, in _call_wrapper\nresult = _call(command, **kwargs_copy)\n
File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
line 291, in _call\nraise
Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
'/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
webhcat: stopping
...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Attachment: AMBARI-15744.trunk.v1.patch
AMBARI-15744.branch-2.2.v1.patch
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Status: Patch Available (was: In Progress)
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230023#comment-15230023
]
Sebastian Toader commented on AMBARI-15744:
---
Committed to trunk:
{code}
commit 1cc4a20b33157de8c547929321567911a13d8942
Author: Toader, Sebastian
Date: Thu Apr 7 11:32:42 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (stoader)
{code}
Committed to branch-2.2:
{code}
commit 5edcf8a275a7ec6f80a6d4456942103e3c8c006c
Author: Toader, Sebastian
Date: Thu Apr 7 11:56:52 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (stoader)
{code}
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.trunk.v1.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Attachment: AMBARI-15744.trunk.v2.patch
AMBARI-15744.branch-2.2.v2.patch
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230212#comment-15230212
]
Sebastian Toader commented on AMBARI-15744:
---
Part2 committed to trunk:
{code}
commit 0e87151795a9bf97f8b7ef8033204b03f08ab91b
Author: Toader, Sebastian
Date: Thu Apr 7 15:08:37 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (part2) (stoader)
{code}
Part2 committed to branch-2.2:
{code}
commit 86a2305c0a8456dfdbe5e80f3cedd1630cad51b1
Author: Toader, Sebastian
Date: Thu Apr 7 15:13:45 2016 +0200
AMBARI-15744. Webhcat Server failed to stop while stopping all the
services. (part2) (stoader)
{code}
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15744) Webhcat Server failed to stop while stopping all the services
[
https://issues.apache.org/jira/browse/AMBARI-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15744:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Webhcat Server failed to stop while stopping all the services
> --
>
> Key: AMBARI-15744
> URL: https://issues.apache.org/jira/browse/AMBARI-15744
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15744.branch-2.2.v1.patch,
> AMBARI-15744.branch-2.2.v2.patch, AMBARI-15744.trunk.v1.patch,
> AMBARI-15744.trunk.v2.patch
>
>
> Stop all the services using Stop All on dashboard. Webhcat server fails to
> stop with the below error. This looks like an intermittent issue.
> {code}
> "/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
> line 155, in \nWebHCatServer().execute()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py\",
> line 219, in execute\nmethod(env)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_server.py\",
>
> line 47, in stop\nwebhcat_service(action='stop')\n File
> \"/usr/lib/python2.6/site-packages/ambari_commons/os_family_impl.py\",
> line 89, in thunk\nreturn fn(*args, **kwargs)\n File
> \"/var/lib/ambari-agent/cache/common-services/HIVE/0.12.0.2.0/package/scripts/webhcat_service.py\",
>
> line 57, in webhcat_service\nenvironment = environ)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/base.py\",
>line 154, in __init__\nself.env.run()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 158, in run\nself.run_action(resource, action)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/environment.py\",
>line 121, in run_action\nprovider_action()\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/providers/system.py\",
>
>line 238, in action_run\ntries=self.resource.tries,
> try_sleep=self.resource.try_sleep)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 70, in inner\nresult = function(command, **kwargs)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
> line 92, in checked_call\ntries=tries, try_sleep=try_sleep)\n
> File \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 140, in _call_wrapper\nresult = _call(command,
> **kwargs_copy)\n File
> \"/usr/lib/python2.6/site-packages/resource_management/core/shell.py\",
>line 291, in _call\nraise
> Fail(err_msg)\nresource_management.core.exceptions.Fail: Execution of
> '/usr/hdp/current/hive-webhcat/sbin/webhcat_server.sh stop' returned 1.
> webhcat: stopping
> ...\n/usr/hdp/2.4.2.0-127/hive-hcatalog/sbin/webhcat_server.sh: failed to stop
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230846#comment-15230846
]
Sebastian Toader commented on AMBARI-15646:
---
Committed to trunk:
{code}
commit 6320d589f942b41cdab34c1de241423ccb5b4752
Author: Daniel Gergely
Date: Thu Apr 7 18:48:43 2016 +0200
AMBARI-15646. Audit Log Code Cleanup & Safety. (Daniel Gergely via stoader)
{code}
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potenti
[jira] [Updated] (AMBARI-15646) Audit Log Code Cleanup & Safety
[
https://issues.apache.org/jira/browse/AMBARI-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15646:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Audit Log Code Cleanup & Safety
> ---
>
> Key: AMBARI-15646
> URL: https://issues.apache.org/jira/browse/AMBARI-15646
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Attachments: AMBARI-15646.patch
>
>
> As a follow-up to AMBARI-15241, there are concerns brought up in review which
> should be addressed but didn't need to hold up the feature being committed.
> These can be further broken out to into separate Jiras if needed:
> - When initializing a ThreadLocal, you can specify an initial value. This
> code is unnecessary:
> {code}
> private ThreadLocal dateFormatThreadLocal = new ThreadLocal<>();
> if(dateFormatThreadLocal.get() == null) {
> //2016-03-11T10:42:36.376Z
> dateFormatThreadLocal.set(new
> SimpleDateFormat("-MM-dd'T'HH:mm:ss.SSSX"));
> }
> {code}
> - There are no tests for a majority of events and event creators.
> - Using a multibinder is fine to be able to inject a {{Set}}, but it's
> not clear to developers adding code that this is what must be done.
> -- We either need to document the super interface to make it clear how to
> have new creators bound
> -- Or annotate creators with an annotation which then be automatically picked
> up by the {{AuditLoggerModule}} and bound without the need to explicitly
> define each creator.
> - {code}
> // binding for audit event creators
> Multibinder auditLogEventCreatorBinder =
> Multibinder.newSetBinder(binder(), RequestAuditEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(DefaultEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ComponentEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(ServiceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(UnauthorizedEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ConfigurationChangeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UserEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(GroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(MemberEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(PrivilegeEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(BlueprintExportEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ServiceConfigDownloadEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(BlueprintEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewInstanceEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ViewPrivilegeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RepositoryEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RepositoryVersionEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertGroupEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(AlertTargetEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(HostEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(UpgradeItemEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(RecommendationIgnoreEventCreator.class);
>
> auditLogEventCreatorBinder.addBinding().to(ValidationIgnoreEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(CredentialEventCreator.class);
> auditLogEventCreatorBinder.addBinding().to(RequestEventCreator.class);
> bind(RequestAuditLogger.class).to(RequestAuditLoggerImpl.class);
> {code}
> - Event creators have nested invocations which is not only hard to read, but
> can potentially cause NPE's; it's a dangerous practice. As an example:
> {code:title=AlertGroupEventCreator}
> String.valueOf(request.getBody().getNamedPropertySets().iterator().next().getProperties().get(PropertyHelper.getPropertyId("AlertGroup",
> "name")));
> {code}
> -- Additionally, this references properties by building them, instead of by
> their registration in the property provider. If the property name ever
> changed, this could easily be missed.
> - Some of the {{auditLog}} methods check to ensure that the logger is enabled
> first. This is very good, as building objects which won't be logged is a
> waste and potential performance problem. However, not all of them do. All
> {{auditLog}} methods should check this first, and return if not enabled. You
> can do this using AOP or just brute-force every method.
> {code}
> pri
[jira] [Commented] (AMBARI-15786) Add some logs to help co-related task ids from server and agent
[ https://issues.apache.org/jira/browse/AMBARI-15786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15234953#comment-15234953 ] Sebastian Toader commented on AMBARI-15786: --- +1 > Add some logs to help co-related task ids from server and agent > --- > > Key: AMBARI-15786 > URL: https://issues.apache.org/jira/browse/AMBARI-15786 > Project: Ambari > Issue Type: Bug > Components: ambari-agent, ambari-server >Affects Versions: 2.2.0 >Reporter: Sumit Mohanty >Assignee: Sumit Mohanty > Fix For: 2.2.2 > > Attachments: AMBARI-15786.patch > > > Recently, I was debugging some cluster and it was very difficult to co-relate > commands that failed with the scheduling of commands from the server. There > are several key log statements that are missing task IDs that can be used to > co-relate the logs. > The changes are modifying only the logs and I have tested that the logs are > being emitted properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
Sebastian Toader created AMBARI-15803: - Summary: Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive Key: AMBARI-15803 URL: https://issues.apache.org/jira/browse/AMBARI-15803 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.2.2 Reporter: Sebastian Toader Assignee: Sebastian Toader Priority: Blocker Fix For: 2.2.2 If a cluster is being provisioned using Blueprint then Ambari server restarted prior all hosts specified in the cluster creation template was assigned to the cluster, than the server becomes unresponsive unable to load the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: AMBARI-15803.trunk.v1.patch AMBARI-15803.branch-2.2.v1.patch > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v1.patch, > AMBARI-15803.trunk.v1.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Status: Patch Available (was: In Progress) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v1.patch, > AMBARI-15803.trunk.v1.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: (was: AMBARI-15803.branch-2.2.v1.patch) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v2.patch, > AMBARI-15803.trunk.v2.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: AMBARI-15803.trunk.v2.patch AMBARI-15803.branch-2.2.v2.patch > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v2.patch, > AMBARI-15803.trunk.v2.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: (was: AMBARI-15803.trunk.v1.patch) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v2.patch, > AMBARI-15803.trunk.v2.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: AMBARI-15803.trunk.v3.patch AMBARI-15803.branch-2.2.v3.patch > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v2.patch, > AMBARI-15803.branch-2.2.v3.patch, AMBARI-15803.trunk.v2.patch, > AMBARI-15803.trunk.v3.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: (was: AMBARI-15803.branch-2.2.v2.patch) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v3.patch, > AMBARI-15803.trunk.v3.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Attachment: (was: AMBARI-15803.trunk.v2.patch) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v3.patch, > AMBARI-15803.trunk.v3.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[ https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15803: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Restarting ambari-server after successful blueprint deploy of large cluster > makes it unresponsive > - > > Key: AMBARI-15803 > URL: https://issues.apache.org/jira/browse/AMBARI-15803 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.2 >Reporter: Sebastian Toader >Assignee: Sebastian Toader >Priority: Blocker > Fix For: 2.2.2 > > Attachments: AMBARI-15803.branch-2.2.v3.patch, > AMBARI-15803.trunk.v3.patch > > > If a cluster is being provisioned using Blueprint then Ambari server > restarted prior all hosts specified in the cluster creation template was > assigned to the cluster, than the server becomes unresponsive unable to load > the cluster from database and continue the cluster creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-15803) Restarting ambari-server after successful blueprint deploy of large cluster makes it unresponsive
[
https://issues.apache.org/jira/browse/AMBARI-15803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237039#comment-15237039
]
Sebastian Toader commented on AMBARI-15803:
---
Committed to trunk:
{code}
commit 2d25706dfb62fb557b6186d0a8c0f512724f39ea
Author: Toader, Sebastian
Date: Tue Apr 12 09:27:22 2016 +0200
AMBARI-15803. Restarting ambari-server after successful blueprint deploy of
large cluster makes it unresponsive. (stoader)
{code}
Committed to branch-2.2:
{code}
commit 7e6877a1589be25499d0a833d3099e612d9b420d
Author: Toader, Sebastian
Date: Tue Apr 12 09:22:06 2016 +0200
AMBARI-15803. Restarting ambari-server after successful blueprint deploy of
large cluster makes it unresponsive. (stoader)
{code}
> Restarting ambari-server after successful blueprint deploy of large cluster
> makes it unresponsive
> -
>
> Key: AMBARI-15803
> URL: https://issues.apache.org/jira/browse/AMBARI-15803
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-15803.branch-2.2.v3.patch,
> AMBARI-15803.trunk.v3.patch
>
>
> If a cluster is being provisioned using Blueprint then Ambari server
> restarted prior all hosts specified in the cluster creation template was
> assigned to the cluster, than the server becomes unresponsive unable to load
> the cluster from database and continue the cluster creation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15804) Audit logging cleanup and tests
[
https://issues.apache.org/jira/browse/AMBARI-15804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238695#comment-15238695
]
Sebastian Toader commented on AMBARI-15804:
---
Committed to trunk:
{code}
commit e0bc22e18b85e16800225076a60606f4e8f13e87
Author: Toader, Sebastian
Date: Tue Apr 12 16:26:59 2016 +0200
AMBARI-15804. Audit logging cleanup and tests (part2). (Daniel Gergely via
stoader)
commit af13ef73931bf672536199b944d4c3e26ad24ac4
Author: Daniel Gergely
Date: Tue Apr 12 14:59:45 2016 +0200
AMBARI-15804. Audit logging cleanup and tests. (Daniel Gergely via stoader)
{code}
> Audit logging cleanup and tests
> ---
>
> Key: AMBARI-15804
> URL: https://issues.apache.org/jira/browse/AMBARI-15804
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-15804.patch
>
>
> Add unit tests for events and event creators, correct auditlog messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15804) Audit logging cleanup and tests
[ https://issues.apache.org/jira/browse/AMBARI-15804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15804: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Audit logging cleanup and tests > --- > > Key: AMBARI-15804 > URL: https://issues.apache.org/jira/browse/AMBARI-15804 > Project: Ambari > Issue Type: Task > Components: ambari-server >Reporter: Daniel Gergely >Assignee: Daniel Gergely > Fix For: 2.4.0 > > Attachments: AMBARI-15804.patch > > > Add unit tests for events and event creators, correct auditlog messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15915) SQL constraints: Inline constraints and name them in CREATE table
Sebastian Toader created AMBARI-15915: - Summary: SQL constraints: Inline constraints and name them in CREATE table Key: AMBARI-15915 URL: https://issues.apache.org/jira/browse/AMBARI-15915 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.4.0 Reporter: Sebastian Toader Fix For: 2.4.0 Move ALTER TABLE statements for unique and foreign key constraints into the CREATE table statement. Also provide primary key constraint names where primary keys are specified. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15978) Blueprint processor does not replace "localhost" in "xasecure.audit.destination.hdfs.dir" property.
Sebastian Toader created AMBARI-15978:
-
Summary: Blueprint processor does not replace "localhost" in
"xasecure.audit.destination.hdfs.dir" property.
Key: AMBARI-15978
URL: https://issues.apache.org/jira/browse/AMBARI-15978
Project: Ambari
Issue Type: Bug
Components: ambari-server
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Priority: Critical
Fix For: 2.2.2
_Audit To HDFS destination directory_ is incorrectly set to
_hdfs://localhost:8020/ranger/audit_. The Blueprint processor should replace
the {{localhost}} placeholder with the host of the NameNode or service name in
case of HA NameNode deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15978) Blueprint processor does not replace "localhost" in "xasecure.audit.destination.hdfs.dir" property.
[
https://issues.apache.org/jira/browse/AMBARI-15978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15978:
--
Attachment: AMBARI-15978.trunk.v1.patch
AMBARI-15978.branch-2.2.v1.patch
> Blueprint processor does not replace "localhost" in
> "xasecure.audit.destination.hdfs.dir" property.
> ---
>
> Key: AMBARI-15978
> URL: https://issues.apache.org/jira/browse/AMBARI-15978
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15978.branch-2.2.v1.patch,
> AMBARI-15978.trunk.v1.patch
>
>
> _Audit To HDFS destination directory_ is incorrectly set to
> _hdfs://localhost:8020/ranger/audit_. The Blueprint processor should replace
> the {{localhost}} placeholder with the host of the NameNode or service name
> in case of HA NameNode deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15978) Blueprint processor does not replace "localhost" in "xasecure.audit.destination.hdfs.dir" property.
[
https://issues.apache.org/jira/browse/AMBARI-15978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15978:
--
Status: Patch Available (was: In Progress)
> Blueprint processor does not replace "localhost" in
> "xasecure.audit.destination.hdfs.dir" property.
> ---
>
> Key: AMBARI-15978
> URL: https://issues.apache.org/jira/browse/AMBARI-15978
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15978.branch-2.2.v1.patch,
> AMBARI-15978.trunk.v1.patch
>
>
> _Audit To HDFS destination directory_ is incorrectly set to
> _hdfs://localhost:8020/ranger/audit_. The Blueprint processor should replace
> the {{localhost}} placeholder with the host of the NameNode or service name
> in case of HA NameNode deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15978) Blueprint processor does not replace "localhost" in "xasecure.audit.destination.hdfs.dir" property.
[
https://issues.apache.org/jira/browse/AMBARI-15978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-15978:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Blueprint processor does not replace "localhost" in
> "xasecure.audit.destination.hdfs.dir" property.
> ---
>
> Key: AMBARI-15978
> URL: https://issues.apache.org/jira/browse/AMBARI-15978
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15978.branch-2.2.v1.patch,
> AMBARI-15978.trunk.v1.patch
>
>
> _Audit To HDFS destination directory_ is incorrectly set to
> _hdfs://localhost:8020/ranger/audit_. The Blueprint processor should replace
> the {{localhost}} placeholder with the host of the NameNode or service name
> in case of HA NameNode deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15978) Blueprint processor does not replace "localhost" in "xasecure.audit.destination.hdfs.dir" property.
[
https://issues.apache.org/jira/browse/AMBARI-15978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249767#comment-15249767
]
Sebastian Toader commented on AMBARI-15978:
---
Committed to trunk:
{code}
commit a26fc867024f91705f8e3e32c6bbc47e6edf89bd
Author: Toader, Sebastian
Date: Wed Apr 20 11:37:47 2016 +0200
AMBARI-15978. Blueprint processor does not replace localhost in
xasecure.audit.destination.hdfs.dir property. (stoader)
{code}
Committed to branch-2.2:
{code}
commit 881af59aaa03722563628d6524d3555b7a3682cb
Author: Toader, Sebastian
Date: Wed Apr 20 11:33:46 2016 +0200
AMBARI-15978. Blueprint processor does not replace localhost in
xasecure.audit.destination.hdfs.dir property. (stoader)
{code}
Committed to branch-2.2.2:
{code}
commit a564058a4acce03403aa645721eaed420288ec24
Author: Toader, Sebastian
Date: Wed Apr 20 11:33:46 2016 +0200
AMBARI-15978. Blueprint processor does not replace localhost in
xasecure.audit.destination.hdfs.dir property. (stoader)
{code}
> Blueprint processor does not replace "localhost" in
> "xasecure.audit.destination.hdfs.dir" property.
> ---
>
> Key: AMBARI-15978
> URL: https://issues.apache.org/jira/browse/AMBARI-15978
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.2.2
>
> Attachments: AMBARI-15978.branch-2.2.v1.patch,
> AMBARI-15978.trunk.v1.patch
>
>
> _Audit To HDFS destination directory_ is incorrectly set to
> _hdfs://localhost:8020/ranger/audit_. The Blueprint processor should replace
> the {{localhost}} placeholder with the host of the NameNode or service name
> in case of HA NameNode deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15915) SQL constraints: Inline constraints and name them in CREATE table
[
https://issues.apache.org/jira/browse/AMBARI-15915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251732#comment-15251732
]
Sebastian Toader commented on AMBARI-15915:
---
Committed to trunk:
{code}
Author: Balazs Bence Sari
Date: Thu Apr 21 13:18:58 2016 +0200
AMBARI-15915. SQL constraints: Inline constraints and name them in CREATE
table. (Balazs Bence Sari via stoader)
{code}
> SQL constraints: Inline constraints and name them in CREATE table
> -
>
> Key: AMBARI-15915
> URL: https://issues.apache.org/jira/browse/AMBARI-15915
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Balázs Bence Sári
> Fix For: 2.4.0
>
> Attachments: patch2.diff
>
>
> Move ALTER TABLE statements for unique and foreign key constraints into the
> CREATE table statement.
> Also provide primary key constraint names where primary keys are specified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMBARI-15915) SQL constraints: Inline constraints and name them in CREATE table
[
https://issues.apache.org/jira/browse/AMBARI-15915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251921#comment-15251921
]
Sebastian Toader commented on AMBARI-15915:
---
{code}
commit 346dfe7eb78b8a71e4981c034fb2f3fddba0db81
Author: Balazs Bence Sari
Date: Thu Apr 21 13:18:58 2016 +0200
AMBARI-15915. SQL constraints: Inline constraints and name them in CREATE
table. (Balazs Bence Sari via stoader)
{code}
> SQL constraints: Inline constraints and name them in CREATE table
> -
>
> Key: AMBARI-15915
> URL: https://issues.apache.org/jira/browse/AMBARI-15915
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Balázs Bence Sári
> Fix For: 2.4.0
>
> Attachments: patch2.diff
>
>
> Move ALTER TABLE statements for unique and foreign key constraints into the
> CREATE table statement.
> Also provide primary key constraint names where primary keys are specified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
Sebastian Toader created AMBARI-16013:
-
Summary: Host_status stuck in UNKNOWN status after blueprint
deploy with host in heartbeat-lost
Key: AMBARI-16013
URL: https://issues.apache.org/jira/browse/AMBARI-16013
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.2.2
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Priority: Blocker
Fix For: 2.2.2
Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
(e.g. nodes already registered with Ambari server once but than all were
stopped prior posting the blueprint/cluster creation template to the server).
The blueprint and cluster creation succeeded and UI looked good with all the
hosts in heartbeat-lost state.
Then start the agents one by one. Expected behaviour is that as soon as all
required nodes are up Ambari to start scheduling tasks on the connected nodes
to install the cluster.
However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16013:
--
Status: Patch Available (was: In Progress)
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v1.patch,
> AMBARI-16013.trunk.v1.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16013:
--
Attachment: AMBARI-16013.trunk.v1.patch
AMBARI-16013.branch-2.2.v1.patch
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v1.patch,
> AMBARI-16013.trunk.v1.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16013:
--
Attachment: (was: AMBARI-16013.trunk.v1.patch)
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v2.patch,
> AMBARI-16013.trunk.v2.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16013:
--
Attachment: AMBARI-16013.trunk.v2.patch
AMBARI-16013.branch-2.2.v2.patch
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v2.patch,
> AMBARI-16013.trunk.v2.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16013:
--
Attachment: (was: AMBARI-16013.branch-2.2.v1.patch)
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v2.patch,
> AMBARI-16013.trunk.v2.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMBARI-15915) SQL constraints: Inline constraints and name them in CREATE table
[ https://issues.apache.org/jira/browse/AMBARI-15915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Toader updated AMBARI-15915: -- Resolution: Fixed Status: Resolved (was: Patch Available) > SQL constraints: Inline constraints and name them in CREATE table > - > > Key: AMBARI-15915 > URL: https://issues.apache.org/jira/browse/AMBARI-15915 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Sebastian Toader >Assignee: Balázs Bence Sári > Fix For: 2.4.0 > > Attachments: patch2.diff > > > Move ALTER TABLE statements for unique and foreign key constraints into the > CREATE table statement. > Also provide primary key constraint names where primary keys are specified. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMBARI-16013) Host_status stuck in UNKNOWN status after blueprint deploy with host in heartbeat-lost
[
https://issues.apache.org/jira/browse/AMBARI-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15252589#comment-15252589
]
Sebastian Toader commented on AMBARI-16013:
---
{code:title=branch-2.2.2}
commit 95bc6b6056f7c87890cb2b1473b2fc72e6be89c4
Author: Toader, Sebastian
Date: Thu Apr 21 19:07:36 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
{code:title=branch-2.2}
commit ff25b1d7f3142d18114b351180c1fff85caa8799
Author: Toader, Sebastian
Date: Thu Apr 21 19:07:36 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
{code:title=trunk}
commit 5b5bf1a34b1b060202421fcdb91a73f47376c273
Author: Toader, Sebastian
Date: Thu Apr 21 19:09:56 2016 +0200
AMBARI-16013. Host_status stuck in UNKNOWN status after blueprint deploy
with host in heartbeat-lost. (stoader)
{code}
> Host_status stuck in UNKNOWN status after blueprint deploy with host in
> heartbeat-lost
> --
>
> Key: AMBARI-16013
> URL: https://issues.apache.org/jira/browse/AMBARI-16013
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.2.2
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Blocker
> Fix For: 2.2.2
>
> Attachments: AMBARI-16013.branch-2.2.v2.patch,
> AMBARI-16013.trunk.v2.patch
>
>
> Deploy a cluster using blueprint when all nodes are in HEARTBEAT_LOST state
> (e.g. nodes already registered with Ambari server once but than all were
> stopped prior posting the blueprint/cluster creation template to the server).
> The blueprint and cluster creation succeeded and UI looked good with all the
> hosts in heartbeat-lost state.
> Then start the agents one by one. Expected behaviour is that as soon as all
> required nodes are up Ambari to start scheduling tasks on the connected
> nodes to install the cluster.
> However the hosts were stuck in {{host_status: UNKNOWN}} state and Ambari did
> not start scheduling any tasks to the connected hosts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMBARI-16119) User imported from AD is unable to login to Ambari.
Sebastian Toader created AMBARI-16119:
-
Summary: User imported from AD is unable to login to Ambari.
Key: AMBARI-16119
URL: https://issues.apache.org/jira/browse/AMBARI-16119
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Sebastian Toader
Assignee: Sebastian Toader
Priority: Critical
Fix For: 2.4.0
Steps to reproduce:
#Install ambari 2.4.0
#Setup ambari with AD server
#Perform "ambari-server sync-ldap --all"
#Try to login to Ambari as one of the users imported AD
The login fails with the following exception in the log:
{code}
20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
/api/v1/users/ambari-d
java.lang.IllegalArgumentException: Cannot pass null or empty values to
constructor
at
org.springframework.security.core.userdetails.User.(User.java:99)
at
org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
at
org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
at
org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
at
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
at
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
at
org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:216)
at
org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:205)
at
org.apache.ambari.server.controller.AmbariHandlerList.handle(AmbariHandlerList.java:139)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Description:
Steps to reproduce:
# Install ambari 2.4.0
# Setup ambari with AD server
# Perform "ambari-server sync-ldap --all"
# Try to login to Ambari as one of the users imported AD
The login fails with the following exception in the log:
{code}
20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
/api/v1/users/ambari-d
java.lang.IllegalArgumentException: Cannot pass null or empty values to
constructor
at
org.springframework.security.core.userdetails.User.(User.java:99)
at
org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
at
org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
at
org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
at
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
at
org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
at
org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
at
org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
at
org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
at
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:216)
at
org.apache.ambari.server.controller.AmbariHandlerList.processHandlers(AmbariHandlerList.java:205)
at
org.apache.ambari.server.controller.AmbariHandlerList.handle(AmbariHandlerList.java:139)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractCo
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: AMBARI-16119.trunk.v1.patch
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v1.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.apache.ambari.server.controller.Amb
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Status: Patch Available (was: Open)
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v1.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.apache.ambari.server.controller.Ambari
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: (was: AMBARI-16119.trunk.v1.patch)
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v2.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.apache.ambari.server.con
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: AMBARI-16119.trunk.v2.patch
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v2.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.apache.ambari.server.controller.Amb
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: (was: AMBARI-16119.trunk.v2.patch)
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v3.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.apache.ambari.server.con
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Attachment: AMBARI-16119.trunk.v3.patch
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v3.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.apache.ambari.server.controller.Amb
[jira] [Commented] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259626#comment-15259626
]
Sebastian Toader commented on AMBARI-16119:
---
Committed to trunk:
{code}
commit fee485798ea0f271f51a41d6e05386ed28b9b755
Author: Toader, Sebastian
Date: Tue Apr 26 21:15:54 2016 +0200
AMBARI-16119. User imported from AD is unable to login to Ambari. (stoader)
{code}
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v3.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185
[jira] [Updated] (AMBARI-16119) User imported from AD is unable to login to Ambari.
[
https://issues.apache.org/jira/browse/AMBARI-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Toader updated AMBARI-16119:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
> User imported from AD is unable to login to Ambari.
> ---
>
> Key: AMBARI-16119
> URL: https://issues.apache.org/jira/browse/AMBARI-16119
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Affects Versions: 2.4.0
>Reporter: Sebastian Toader
>Assignee: Sebastian Toader
>Priority: Critical
> Fix For: 2.4.0
>
> Attachments: AMBARI-16119.trunk.v3.patch
>
>
> Steps to reproduce:
> # Install ambari 2.4.0
> # Setup ambari with AD server
> # Perform "ambari-server sync-ldap --all"
> # Try to login to Ambari as one of the users imported AD
> The login fails with the following exception in the log:
> {code}
> 20 Apr 2016 15:26:38,891 INFO [qtp-ambari-client-28]
> FilterBasedLdapUserSearch:89 - SearchBase not set. Searches will be performed
> from the root: cn=Users,dc=hwqe,dc=hortonworks,dc=com
> 20 Apr 2016 15:26:40,830 WARN [qtp-ambari-client-28] ServletHandler:628 -
> /api/v1/users/ambari-d
> java.lang.IllegalArgumentException: Cannot pass null or empty values to
> constructor
> at
> org.springframework.security.core.userdetails.User.(User.java:99)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.getPrincipalOverride(AmbariAuthentication.java:196)
> at
> org.apache.ambari.server.security.authorization.AmbariAuthentication.(AmbariAuthentication.java:40)
> at
> org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProvider.authenticate(AmbariLdapAuthenticationProvider.java:66)
> at
> org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156)
> at
> org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:168)
> at
> org.apache.ambari.server.security.authentication.AmbariAuthenticationFilter.doFilter(AmbariAuthenticationFilter.java:88)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87)
> at
> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342)
> at
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192)
> at
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
> at
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
> at
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.MethodOverrideFilter.doFilter(MethodOverrideFilter.java:72)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.api.AmbariPersistFilter.doFilter(AmbariPersistFilter.java:47)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.apache.ambari.server.security.AbstractSecurityHeaderFilter.doFilter(AbstractSecurityHeaderFilter.java:109)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
> at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.apache.a
[jira] [Commented] (AMBARI-16150) Killing hive metastore and webhcat might fail with "no process" error
[
https://issues.apache.org/jira/browse/AMBARI-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263691#comment-15263691
]
Sebastian Toader commented on AMBARI-16150:
---
Committed to trunk:
{code}
commit 6915791523e0cfc73019bb06b082db12abb03303
Author: Daniel Gergely
Date: Thu Apr 28 12:47:37 2016 +0200
AMBARI-16150. Killing hive metastore and webhcat might fail with "no
process" error. (Daniel Gergely via stoader)
{code}
> Killing hive metastore and webhcat might fail with "no process" error
> -
>
> Key: AMBARI-16150
> URL: https://issues.apache.org/jira/browse/AMBARI-16150
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
>Reporter: Daniel Gergely
>Assignee: Daniel Gergely
> Fix For: 2.4.0
>
> Attachments: AMBARI-16150.patch
>
>
> When killing hive metastore and webhcat a graceful and a hard kill is issued.
> If the graceful kill is successful, but not quick enough, it is possible that
> hard kill also issued, but in the meantime the process stops. So when hard
> kill executes no process runs and this results in a failure.
> Hard kill in other places have the flag ignore_failures=True, but it is
> missing from hive related services, this should be added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
