[
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 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
