[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-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)
