[jira] [Updated] (AMBARI-17580) Unable to add MASTER component on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-17580: -- Status: Open (was: Patch Available) > Unable to add MASTER component on all nodes > --- > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-17580.patch > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17580) Unable to add MASTER component on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-17580: -- Attachment: AMBARI-17580_branch-2.4.patch > Unable to add MASTER component on all nodes > --- > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-17580_branch-2.4.patch > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17580) Unable to add MASTER component on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-17580: -- Status: Patch Available (was: Open) > Unable to add MASTER component on all nodes > --- > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-17580_branch-2.4.patch > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17580) Unable to add MASTER component on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-17580: -- Attachment: (was: AMBARI-17580.patch) > Unable to add MASTER component on all nodes > --- > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17580) Unable to add MASTER component on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-17580: -- Labels: patch (was: ) Status: Patch Available (was: Open) > Unable to add MASTER component on all nodes > --- > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-17580.patch > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-17580) Unable to add MASTER component on all nodes
[ https://issues.apache.org/jira/browse/AMBARI-17580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-17580: -- Attachment: AMBARI-17580.patch > Unable to add MASTER component on all nodes > --- > > Key: AMBARI-17580 > URL: https://issues.apache.org/jira/browse/AMBARI-17580 > Project: Ambari > Issue Type: Bug > Components: ambari-web >Affects Versions: 2.3.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Labels: patch > Fix For: 2.4.0 > > Attachments: AMBARI-17580.patch > > > While trying to add a MASTER component with cardinality ALL: > org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: > Attempted to create a host_component which already exists: [clusterName=HDP, > hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-17580) Unable to add MASTER component on all nodes
Shantanu Mundkur created AMBARI-17580: - Summary: Unable to add MASTER component on all nodes Key: AMBARI-17580 URL: https://issues.apache.org/jira/browse/AMBARI-17580 Project: Ambari Issue Type: Bug Components: ambari-web Affects Versions: 2.3.0 Reporter: Shantanu Mundkur Assignee: Shantanu Mundkur Fix For: 2.4.0 While trying to add a MASTER component with cardinality ALL: org.apache.ambari.server.controller.spi.ResourceAlreadyExistsException: Attempted to create a host_component which already exists: [clusterName=HDP, hostName=node1.mydomain.com, componentName=SERVICE_MASTER] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15395) Enhance blueprint support for using references
[ https://issues.apache.org/jira/browse/AMBARI-15395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15395: -- Attachment: Blueprints_enhancement-AMBARI-15395-v3.pdf > Enhance blueprint support for using references > -- > > Key: AMBARI-15395 > URL: https://issues.apache.org/jira/browse/AMBARI-15395 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Shantanu Mundkur >Assignee: Amruta Borkar > Attachments: Blueprints_enhancement-AMBARI-15395-v3.docx, > Blueprints_enhancement-AMBARI-15395-v3.pdf > > > An exported blueprint should provide ready portability i.e. an exported > blueprint be usable without changes to deploy another cluster. Some elements > that are masked or omitted use tokens or placeholders. These have been called > references in previous Jiras. A reference follow some convention that > indicates that it is a reference by using a keyword and a pattern e.g. > ReferenceName:configType:configVersion:propertyName > References would be a good indicators of properties that user could choose to > customize before deploying the cluster. It could also indicate the need for a > "global" default for that property in the cluster template. Examples: > - Passwords > - Hostnames > - External databases > Currently Ambari has a concept of SECRET references. E.g. > SECRET:hive-site:2:hive.server2.keystore.password > These are used for masking the password when a blueprint is exported and the > reference itself is not exported. It would be useful to have an reference > exported as long as it is processed appropriately during deployment. > Similar to the secret reference, for hostnames in a one could have, > HOST:kerberos-env:-1:kdc_host > and so forth. > For any reference, in the cluster template there would be a corresponding > property that would be used for substituting a value for the reference during > deployment if the registered blueprint had such references. Currently such > behavior is used if a property of type password is not specified > (default_password). Such references could be used to tag properties to flag > them to be the ones that users must customize or include in the cluster > template. They can also serve a way to annotate/comment parts of the > blueprint JSON. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15395) Enhance blueprint support for using references
[ https://issues.apache.org/jira/browse/AMBARI-15395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15395: -- Attachment: Blueprints_enhancement-AMBARI-15395-v3.docx > Enhance blueprint support for using references > -- > > Key: AMBARI-15395 > URL: https://issues.apache.org/jira/browse/AMBARI-15395 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Shantanu Mundkur >Assignee: Amruta Borkar > Attachments: Blueprints_enhancement-AMBARI-15395-v3.docx > > > An exported blueprint should provide ready portability i.e. an exported > blueprint be usable without changes to deploy another cluster. Some elements > that are masked or omitted use tokens or placeholders. These have been called > references in previous Jiras. A reference follow some convention that > indicates that it is a reference by using a keyword and a pattern e.g. > ReferenceName:configType:configVersion:propertyName > References would be a good indicators of properties that user could choose to > customize before deploying the cluster. It could also indicate the need for a > "global" default for that property in the cluster template. Examples: > - Passwords > - Hostnames > - External databases > Currently Ambari has a concept of SECRET references. E.g. > SECRET:hive-site:2:hive.server2.keystore.password > These are used for masking the password when a blueprint is exported and the > reference itself is not exported. It would be useful to have an reference > exported as long as it is processed appropriately during deployment. > Similar to the secret reference, for hostnames in a one could have, > HOST:kerberos-env:-1:kdc_host > and so forth. > For any reference, in the cluster template there would be a corresponding > property that would be used for substituting a value for the reference during > deployment if the registered blueprint had such references. Currently such > behavior is used if a property of type password is not specified > (default_password). Such references could be used to tag properties to flag > them to be the ones that users must customize or include in the cluster > template. They can also serve a way to annotate/comment parts of the > blueprint JSON. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Attachment: AMBARI-15496-2.patch More UT updates > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496-2.patch, AMBARI-15496.patch, > AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Status: Patch Available (was: Open) > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496-2.patch, AMBARI-15496.patch, > AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Status: Open (was: Patch Available) > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch, AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Attachment: AMBARI-15496.patch > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch, AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Status: Open (was: Patch Available) > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch, AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Status: Patch Available (was: Open) > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Attachment: AMBARI-15496.patch > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Attachment: (was: AMBARI-15496.patch) > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Status: Open (was: Patch Available) > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Status: Open (was: Patch Available) > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Attachment: AMBARI-15496.patch > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0, 2.2.1 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Attachment: AMBARI-15496.patch > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > Attachments: AMBARI-15496.patch > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15496) /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file contains various passwords in plain text in world readable file
[ https://issues.apache.org/jira/browse/AMBARI-15496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15496: -- Fix Version/s: (was: 2.2.0) trunk > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json file > contains various passwords in plain text in world readable file > -- > > Key: AMBARI-15496 > URL: https://issues.apache.org/jira/browse/AMBARI-15496 > Project: Ambari > Issue Type: Bug > Components: ambari-agent >Affects Versions: 2.1.0, 2.2.0 >Reporter: Austin Clifford >Assignee: Shantanu Mundkur > Labels: security > Fix For: trunk > > > Various passwords are in plain text in world readable configurations.json file > $ ls -altr > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json > -rw-r--r-- 1 root root 176342 Mar 4 08:55 > /var/lib/ambari-agent/cache/cluster_configuration/configurations.json -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15454) Blueprint install using config_recommendation_strategy is not functional
Shantanu Mundkur created AMBARI-15454: - Summary: Blueprint install using config_recommendation_strategy is not functional Key: AMBARI-15454 URL: https://issues.apache.org/jira/browse/AMBARI-15454 Project: Ambari Issue Type: Bug Components: ambari-server Affects Versions: 2.2.0, 2.2.1 Reporter: Shantanu Mundkur Assignee: Shantanu Mundkur Fix For: trunk, 2.4.0 Blueprint install using config_recommendation strategy seems to hang for a long time (couple of hours?) and ends up logging exceptions continually to ambari-server.log. At the same time many hundreds of directories are seen getting created under /var/run/ambari-server/stack-recommendations (I have seen above 800-900). If you keep it running eventually the cluster install seems to start but fails miserably at least during the start and some of it makes obvious that configuration recommendations were NOT applied. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15454) Blueprint install using config_recommendation_strategy is not functional
[ https://issues.apache.org/jira/browse/AMBARI-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15454: -- Attachment: (was: AMBARI-15454.patch) > Blueprint install using config_recommendation_strategy is not functional > > > Key: AMBARI-15454 > URL: https://issues.apache.org/jira/browse/AMBARI-15454 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0, 2.2.1 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-15454.patch > > > Blueprint install using config_recommendation strategy seems to hang for a > long time (couple of hours?) and ends up logging exceptions continually to > ambari-server.log. At the same time many hundreds of directories are seen > getting created under /var/run/ambari-server/stack-recommendations (I have > seen above 800-900). If you keep it running eventually the cluster install > seems to start but fails miserably at least during the start and some of it > makes obvious that configuration recommendations were NOT applied. > 14 Mar 2016 23:26:33,784 ERROR [pool-8-thread-1] TopologyManager:737 - > TopologyManager.ConfigureClusterTask: An exception occurred while attempting > to process cluster configs and set on cluster: > java.lang.NullPointerException > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) > at com.google.common.collect.Maps.filterKeys(Maps.java:2089) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterStackDefaults(BlueprintConfigurationProcessor.java:445) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doRecommendConfigurations(BlueprintConfigurationProcessor.java:418) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:225) > at > org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:97) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:735) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) > 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) > 14 Mar 2016 23:26:33,784 INFO [pool-3-thread-1] AsyncCallableService:111 - > Exception during task execution: > java.util.concurrent.ExecutionException: java.lang.Exception: > java.lang.NullPointerException > 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.NullPointerException > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:741) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) > 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) > ... 3 more > Caused by: java.lang.NullPointerException > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) > at
[jira] [Updated] (AMBARI-15454) Blueprint install using config_recommendation_strategy is not functional
[ https://issues.apache.org/jira/browse/AMBARI-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15454: -- Description: Blueprint install using config_recommendation strategy seems to hang for a long time (couple of hours?) and ends up logging exceptions continually to ambari-server.log. At the same time many hundreds of directories are seen getting created under /var/run/ambari-server/stack-recommendations (I have seen above 800-900). If you keep it running eventually the cluster install seems to start but fails miserably at least during the start and some of it makes obvious that configuration recommendations were NOT applied. 14 Mar 2016 23:26:33,784 ERROR [pool-8-thread-1] TopologyManager:737 - TopologyManager.ConfigureClusterTask: An exception occurred while attempting to process cluster configs and set on cluster: java.lang.NullPointerException at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) at com.google.common.collect.Maps.filterKeys(Maps.java:2089) at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterStackDefaults(BlueprintConfigurationProcessor.java:445) at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doRecommendConfigurations(BlueprintConfigurationProcessor.java:418) at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:225) at org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:97) at org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:735) at org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) 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) 14 Mar 2016 23:26:33,784 INFO [pool-3-thread-1] AsyncCallableService:111 - Exception during task execution: java.util.concurrent.ExecutionException: java.lang.Exception: java.lang.NullPointerException 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.NullPointerException at org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:741) at org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) 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) ... 3 more Caused by: java.lang.NullPointerException at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) at com.google.common.collect.Maps.filterKeys(Maps.java:2089) at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterStackDefaults(BlueprintConfigurationProcessor.java:445) at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doRecommendConfigurations(BlueprintConfigurationProcessor.java:418) at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:225) at org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:97) at org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:735)
[jira] [Updated] (AMBARI-15454) Blueprint install using config_recommendation_strategy is not functional
[ https://issues.apache.org/jira/browse/AMBARI-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15454: -- Attachment: AMBARI-15454.patch > Blueprint install using config_recommendation_strategy is not functional > > > Key: AMBARI-15454 > URL: https://issues.apache.org/jira/browse/AMBARI-15454 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0, 2.2.1 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-15454.patch > > > Blueprint install using config_recommendation strategy seems to hang for a > long time (couple of hours?) and ends up logging exceptions continually to > ambari-server.log. At the same time many hundreds of directories are seen > getting created under /var/run/ambari-server/stack-recommendations (I have > seen above 800-900). If you keep it running eventually the cluster install > seems to start but fails miserably at least during the start and some of it > makes obvious that configuration recommendations were NOT applied. > 14 Mar 2016 23:26:33,784 ERROR [pool-8-thread-1] TopologyManager:737 - > TopologyManager.ConfigureClusterTask: An exception occurred while attempting > to process cluster configs and set on cluster: > java.lang.NullPointerException > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) > at com.google.common.collect.Maps.filterKeys(Maps.java:2089) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterStackDefaults(BlueprintConfigurationProcessor.java:445) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doRecommendConfigurations(BlueprintConfigurationProcessor.java:418) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:225) > at > org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:97) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:735) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) > 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) > 14 Mar 2016 23:26:33,784 INFO [pool-3-thread-1] AsyncCallableService:111 - > Exception during task execution: > java.util.concurrent.ExecutionException: java.lang.Exception: > java.lang.NullPointerException > 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.NullPointerException > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:741) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) > 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) > ... 3 more > Caused by: java.lang.NullPointerException > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) > at com.google.common.collect.Maps.filterKeys(Maps.java:2089)
[jira] [Updated] (AMBARI-15454) Blueprint install using config_recommendation_strategy is not functional
[ https://issues.apache.org/jira/browse/AMBARI-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15454: -- Status: Patch Available (was: Open) > Blueprint install using config_recommendation_strategy is not functional > > > Key: AMBARI-15454 > URL: https://issues.apache.org/jira/browse/AMBARI-15454 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0, 2.2.1 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-15454.patch > > > Blueprint install using config_recommendation strategy seems to hang for a > long time (couple of hours?) and ends up logging exceptions continually to > ambari-server.log. At the same time many hundreds of directories are seen > getting created under /var/run/ambari-server/stack-recommendations (I have > seen above 800-900). If you keep it running eventually the cluster install > seems to start but fails miserably at least during the start and some of it > makes obvious that configuration recommendations were NOT applied. > 14 Mar 2016 23:26:33,784 ERROR [pool-8-thread-1] TopologyManager:737 - > TopologyManager.ConfigureClusterTask: An exception occurred while attempting > to process cluster configs and set on cluster: > java.lang.NullPointerException > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) > at com.google.common.collect.Maps.filterKeys(Maps.java:2089) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterStackDefaults(BlueprintConfigurationProcessor.java:445) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doRecommendConfigurations(BlueprintConfigurationProcessor.java:418) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:225) > at > org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:97) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:735) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) > 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) > 14 Mar 2016 23:26:33,784 INFO [pool-3-thread-1] AsyncCallableService:111 - > Exception during task execution: > java.util.concurrent.ExecutionException: java.lang.Exception: > java.lang.NullPointerException > 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.NullPointerException > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:741) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) > 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) > ... 3 more > Caused by: java.lang.NullPointerException > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) > at
[jira] [Updated] (AMBARI-15454) Blueprint install using config_recommendation_strategy is not functional
[ https://issues.apache.org/jira/browse/AMBARI-15454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15454: -- Status: Patch Available (was: Open) > Blueprint install using config_recommendation_strategy is not functional > > > Key: AMBARI-15454 > URL: https://issues.apache.org/jira/browse/AMBARI-15454 > Project: Ambari > Issue Type: Bug > Components: ambari-server >Affects Versions: 2.2.0, 2.2.1 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-15454.patch > > > Blueprint install using config_recommendation strategy seems to hang for a > long time (couple of hours?) and ends up logging exceptions continually to > ambari-server.log. At the same time many hundreds of directories are seen > getting created under /var/run/ambari-server/stack-recommendations (I have > seen above 800-900). If you keep it running eventually the cluster install > seems to start but fails miserably at least during the start and some of it > makes obvious that configuration recommendations were NOT applied. > 14 Mar 2016 23:26:33,784 ERROR [pool-8-thread-1] TopologyManager:737 - > TopologyManager.ConfigureClusterTask: An exception occurred while attempting > to process cluster configs and set on cluster: > java.lang.NullPointerException > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) > at com.google.common.collect.Maps.filterKeys(Maps.java:2089) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doFilterStackDefaults(BlueprintConfigurationProcessor.java:445) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doRecommendConfigurations(BlueprintConfigurationProcessor.java:418) > at > org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:225) > at > org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:97) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:735) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) > 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) > 14 Mar 2016 23:26:33,784 INFO [pool-3-thread-1] AsyncCallableService:111 - > Exception during task execution: > java.util.concurrent.ExecutionException: java.lang.Exception: > java.lang.NullPointerException > 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.NullPointerException > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:741) > at > org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:709) > 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) > ... 3 more > Caused by: java.lang.NullPointerException > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191) > at
[jira] [Updated] (AMBARI-15395) Enhance blueprint support for using references
[ https://issues.apache.org/jira/browse/AMBARI-15395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15395: -- Description: An exported blueprint should provide ready portability i.e. an exported blueprint be usable without changes to deploy another cluster. Some elements that are masked or omitted use tokens or placeholders. These have been called references in previous Jiras. A reference follow some convention that indicates that it is a reference by using a keyword and a pattern e.g. ReferenceName:configType:configVersion:propertyName References would be a good indicators of properties that user could choose to customize before deploying the cluster. It could also indicate the need for a "global" default for that property in the cluster template. Examples: - Passwords - Hostnames - External databases Currently Ambari has a concept of SECRET references. E.g. SECRET:hive-site:2:hive.server2.keystore.password These are used for masking the password when a blueprint is exported and the reference itself is not exported. It would be useful to have an reference exported as long as it is processed appropriately during deployment. Similar to the secret reference, for hostnames in a one could have, HOST:kerberos-env:-1:kdc_host and so forth. For any reference, in the cluster template there would be a corresponding property that would be used for substituting a value for the reference during deployment if the registered blueprint had such references. Currently such behavior is used if a property of type password is not specified (default_password). Such references could be used to tag properties to flag them to be the ones that users must customize or include in the cluster template. It could also serve a way to annotate/comment parts of the blueprint JSON. was: An exported blueprint should provide ready portability i.e. an exported blueprint be usable without changes to deploy another cluster; some elements that are masked or omitted could still use tokens or placeholders. These have been called references in previous Jiras. A reference follow some convention that indicates that it is a reference by using a keyword and a pattern e.g. ReferenceName:configType:configVersion:propertyName References would be a good indicators of properties that user could choose to customize before deploying the cluster. It could also indicate the need for a "global" default for that property in the cluster template. Examples: Passwords Hostnames External databases Currently Ambari has a concept of SECRET references. E.g. SECRET:hive-site:2:hive.server2.keystore.password These are used for masking the password when a blueprint is exported and the reference itself is not exported. It would be useful to have an reference exported as long as it is processed appropriately during deployment. Similar to the secret reference, one could have, HOST:kerberos-env:-1:kdc_host and so forth. For any reference, in the cluster template there would be a corresponding property that would be used for substituting a value for the reference during deployment if the registered blueprint had such references. Currently such behavior is used if a property of type password is not specified (default_password). Such references could be used to tag properties to flag them to be the ones that users must customize or include in the cluster template. It could also serve a way to annotate/comment parts of the blueprint JSON. > Enhance blueprint support for using references > -- > > Key: AMBARI-15395 > URL: https://issues.apache.org/jira/browse/AMBARI-15395 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Shantanu Mundkur > > An exported blueprint should provide ready portability i.e. an exported > blueprint be usable without changes to deploy another cluster. Some elements > that are masked or omitted use tokens or placeholders. These have been called > references in previous Jiras. A reference follow some convention that > indicates that it is a reference by using a keyword and a pattern e.g. > ReferenceName:configType:configVersion:propertyName > References would be a good indicators of properties that user could choose to > customize before deploying the cluster. It could also indicate the need for a > "global" default for that property in the cluster template. Examples: > - Passwords > - Hostnames > - External databases > Currently Ambari has a concept of SECRET references. E.g. > SECRET:hive-site:2:hive.server2.keystore.password > These are used for masking the password when a blueprint is exported and the > reference itself is not exported. It would be useful to have
[jira] [Updated] (AMBARI-15395) Enhance blueprint support for using references
[ https://issues.apache.org/jira/browse/AMBARI-15395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15395: -- Description: An exported blueprint should provide ready portability i.e. an exported blueprint be usable without changes to deploy another cluster; some elements that are masked or omitted could still use tokens or placeholders. These have been called references in previous Jiras. A reference follow some convention that indicates that it is a reference by using a keyword and a pattern e.g. ReferenceName:configType:configVersion:propertyName References would be a good indicators of properties that user could choose to customize before deploying the cluster. It could also indicate the need for a "global" default for that property in the cluster template. Examples: Passwords Hostnames External databases Currently Ambari has a concept of SECRET references. E.g. SECRET:hive-site:2:hive.server2.keystore.password These are used for masking the password when a blueprint is exported and the reference itself is not exported. It would be useful to have an reference exported as long as it is processed appropriately during deployment. Similar to the secret reference, one could have, HOST:kerberos-env:-1:kdc_host and so forth. For any reference, in the cluster template there would be a corresponding property that would be used for substituting a value for the reference during deployment if the registered blueprint had such references. Currently such behavior is used if a property of type password is not specified (default_password). Such references could be used to tag properties to flag them to be the ones that users must customize or include in the cluster template. It could also serve a way to annotate/comment parts of the blueprint JSON. was: An exported blueprint should provide ready portability i.e. an exported blueprint be usable without changes to deploy another cluster; some elements that are masked or omitted could still use tokens or placeholders. These have been called references in previous Jiras. A reference follow some convention that indicates that it is a reference by using a keyword and a pattern e.g. ReferenceName:configType:configVersion:propertyName References would be a good indicators of properties that user could choose to customize before deploying the cluster. It could also indicate the need for a "global" default for that property in the cluster template. Examples: Passwords Hostnames External databases Currently Ambari has a concept of SECRET references. E.g. SECRET:hive-site:2:hive.server2.keystore.password These are used for masking the password when a blueprint is exported. However, it would be useful to have an entry exported but using a reference. Similarly one could have, HOST:kerberos-env:-1:kdc_host and so forth. For any reference, in the cluster template there would be a corresponding property that would be used for substituting a value for the reference during deployment if the registered blueprint had such references. Currently such behavior is used if a property of type password is not specified (default_password). Such references could be used to tag properties to flag them to be the ones that users must customize or include in the cluster template. It could also serve a way to annotate/comment parts of the blueprint JSON. > Enhance blueprint support for using references > -- > > Key: AMBARI-15395 > URL: https://issues.apache.org/jira/browse/AMBARI-15395 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Shantanu Mundkur > > An exported blueprint should provide ready portability i.e. an exported > blueprint be usable without changes to deploy another cluster; some elements > that are masked or omitted could still use tokens or placeholders. These have > been called references in previous Jiras. A reference follow some convention > that indicates that it is a reference by using a keyword and a pattern e.g. > ReferenceName:configType:configVersion:propertyName > References would be a good indicators of properties that user could choose to > customize before deploying the cluster. It could also indicate the need for a > "global" default for that property in the cluster template. Examples: > Passwords > Hostnames > External databases > Currently Ambari has a concept of SECRET references. E.g. > SECRET:hive-site:2:hive.server2.keystore.password > These are used for masking the password when a blueprint is exported and the > reference itself is not exported. It would be useful to have an reference > exported as long as it is processed appropriately during deployment. > Similar to the secret reference, one could
[jira] [Updated] (AMBARI-15395) Enhance blueprint support for using references
[ https://issues.apache.org/jira/browse/AMBARI-15395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15395: -- Description: An exported blueprint should provide ready portability i.e. an exported blueprint be usable without changes to deploy another cluster; some elements that are masked or omitted could still use tokens or placeholders. These have been called references in previous Jiras. A reference follow some convention that indicates that it is a reference by using a keyword and a pattern e.g. ReferenceName:configType:configVersion:propertyName References would be a good indicators of properties that user could choose to customize before deploying the cluster. It could also indicate the need for a "global" default for that property in the cluster template. Examples: Passwords Hostnames External databases Currently Ambari has a concept of SECRET references. E.g. SECRET:hive-site:2:hive.server2.keystore.password These are used for masking the password when a blueprint is exported. However, it would be useful to have an entry exported but using a reference. Similarly one could have, HOST:kerberos-env:-1:kdc_host and so forth. For any reference, in the cluster template there would be a corresponding property that would be used for substituting a value for the reference during deployment if the registered blueprint had such references. Currently such behavior is used if a property of type password is not specified (default_password). Such references could be used to tag properties to flag them to be the ones that users must customize or include in the cluster template. It could also serve a way to annotate/comment parts of the blueprint JSON. > Enhance blueprint support for using references > -- > > Key: AMBARI-15395 > URL: https://issues.apache.org/jira/browse/AMBARI-15395 > Project: Ambari > Issue Type: Story > Components: ambari-server >Affects Versions: 2.4.0 >Reporter: Shantanu Mundkur > > An exported blueprint should provide ready portability i.e. an exported > blueprint be usable without changes to deploy another cluster; some elements > that are masked or omitted could still use tokens or placeholders. These have > been called references in previous Jiras. A reference follow some convention > that indicates that it is a reference by using a keyword and a pattern e.g. > ReferenceName:configType:configVersion:propertyName > References would be a good indicators of properties that user could choose to > customize before deploying the cluster. It could also indicate the need for a > "global" default for that property in the cluster template. Examples: > Passwords > Hostnames > External databases > Currently Ambari has a concept of SECRET references. E.g. > SECRET:hive-site:2:hive.server2.keystore.password > These are used for masking the password when a blueprint is exported. > However, it would be useful to have an entry exported but using a reference. > Similarly one could have, > HOST:kerberos-env:-1:kdc_host > and so forth. > For any reference, in the cluster template there would be a corresponding > property that would be used for substituting a value for the reference during > deployment if the registered blueprint had such references. Currently such > behavior is used if a property of type password is not specified > (default_password). Such references could be used to tag properties to flag > them to be the ones that users must customize or include in the cluster > template. It could also serve a way to annotate/comment parts of the > blueprint JSON. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMBARI-15395) Enhance blueprint support for using references
Shantanu Mundkur created AMBARI-15395: - Summary: Enhance blueprint support for using references Key: AMBARI-15395 URL: https://issues.apache.org/jira/browse/AMBARI-15395 Project: Ambari Issue Type: Story Components: ambari-server Affects Versions: 2.4.0 Reporter: Shantanu Mundkur -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15331) AMS HBase FIFO compaction policy and Normalizer settings are not handled correctly
[ https://issues.apache.org/jira/browse/AMBARI-15331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15331: -- Attachment: (was: AMBARI-15331.patch2) > AMS HBase FIFO compaction policy and Normalizer settings are not handled > correctly > -- > > Key: AMBARI-15331 > URL: https://issues.apache.org/jira/browse/AMBARI-15331 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.2.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-15331.patch > > > AMS HBase FIFO compaction policy and Normalizer settings are not handled > correctly. > A user could change the defaults for these settings via configuration updates > but at least two problems would result. > 1) Updates to variables AMS_HBASE_FIFO_COMPACTION_ENABLED and > AMS_HBASE_NORMALIZER_ENABLED will not be honored. Same would be the case for > the recent addition to ams-env - AMS_HBASE_INIT_CHECK_ENABLED. > 2) During upgrade to Ambari 2.2.0 these settings will not be correctly > handled due to incorrect variable names and leads to exceptions e.g if > AMS_HBASE_FIFO_COMPACTION_ENABLED was expected to be set to 'false', for > instance if the AMS HBase version did not support FIFO compaction policy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15331) AMS HBase FIFO compaction policy and Normalizer settings are not handled correctly
[ https://issues.apache.org/jira/browse/AMBARI-15331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15331: -- Attachment: (was: AMBARI-15331.patch) > AMS HBase FIFO compaction policy and Normalizer settings are not handled > correctly > -- > > Key: AMBARI-15331 > URL: https://issues.apache.org/jira/browse/AMBARI-15331 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.2.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-15331.patch > > > AMS HBase FIFO compaction policy and Normalizer settings are not handled > correctly. > A user could change the defaults for these settings via configuration updates > but at least two problems would result. > 1) Updates to variables AMS_HBASE_FIFO_COMPACTION_ENABLED and > AMS_HBASE_NORMALIZER_ENABLED will not be honored. Same would be the case for > the recent addition to ams-env - AMS_HBASE_INIT_CHECK_ENABLED. > 2) During upgrade to Ambari 2.2.0 these settings will not be correctly > handled due to incorrect variable names and leads to exceptions e.g if > AMS_HBASE_FIFO_COMPACTION_ENABLED was expected to be set to 'false', for > instance if the AMS HBase version did not support FIFO compaction policy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15331) AMS HBase FIFO compaction policy and Normalizer settings are not handled correctly
[ https://issues.apache.org/jira/browse/AMBARI-15331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15331: -- Attachment: AMBARI-15331.patch > AMS HBase FIFO compaction policy and Normalizer settings are not handled > correctly > -- > > Key: AMBARI-15331 > URL: https://issues.apache.org/jira/browse/AMBARI-15331 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.2.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-15331.patch > > > AMS HBase FIFO compaction policy and Normalizer settings are not handled > correctly. > A user could change the defaults for these settings via configuration updates > but at least two problems would result. > 1) Updates to variables AMS_HBASE_FIFO_COMPACTION_ENABLED and > AMS_HBASE_NORMALIZER_ENABLED will not be honored. Same would be the case for > the recent addition to ams-env - AMS_HBASE_INIT_CHECK_ENABLED. > 2) During upgrade to Ambari 2.2.0 these settings will not be correctly > handled due to incorrect variable names and leads to exceptions e.g if > AMS_HBASE_FIFO_COMPACTION_ENABLED was expected to be set to 'false', for > instance if the AMS HBase version did not support FIFO compaction policy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMBARI-15331) AMS HBase FIFO compaction policy and Normalizer settings are not handled correctly
[ https://issues.apache.org/jira/browse/AMBARI-15331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shantanu Mundkur updated AMBARI-15331: -- Status: Open (was: Patch Available) > AMS HBase FIFO compaction policy and Normalizer settings are not handled > correctly > -- > > Key: AMBARI-15331 > URL: https://issues.apache.org/jira/browse/AMBARI-15331 > Project: Ambari > Issue Type: Bug > Components: ambari-metrics >Affects Versions: 2.2.0 >Reporter: Shantanu Mundkur >Assignee: Shantanu Mundkur > Fix For: trunk, 2.4.0 > > Attachments: AMBARI-15331.patch > > > AMS HBase FIFO compaction policy and Normalizer settings are not handled > correctly. > A user could change the defaults for these settings via configuration updates > but at least two problems would result. > 1) Updates to variables AMS_HBASE_FIFO_COMPACTION_ENABLED and > AMS_HBASE_NORMALIZER_ENABLED will not be honored. Same would be the case for > the recent addition to ams-env - AMS_HBASE_INIT_CHECK_ENABLED. > 2) During upgrade to Ambari 2.2.0 these settings will not be correctly > handled due to incorrect variable names and leads to exceptions e.g if > AMS_HBASE_FIFO_COMPACTION_ENABLED was expected to be set to 'false', for > instance if the AMS HBase version did not support FIFO compaction policy. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
