You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Shantanu Mundkur (JIRA)" <ji...@apache.org> on 2016/03/11 22:58:53 UTC

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