incubator-ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Siddharth Wagle (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-2819) Extending Stack definition to remove duplication in stack metadata info.
Date Fri, 13 Sep 2013 22:34:53 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Siddharth Wagle updated AMBARI-2819:
------------------------------------

    Attachment: AMBARI-2819.patch

*private String parentVersion;*
   Why do we need to expose the parent version. Is this relevant to the API consumer?

- Since the only way to look at a deployed cluster and find out how the service definition
is computed, is by following the parent version chain. This is for someone with access to
API but not the server host with XML definitions.

- Added \@Override tag

- Unit tests added:
# New config property
# Property that did not change
# AmbariManagementController.testReInstallClientComponent - 1.2.0 to 2.0.6
# Added test for getParentStacksInOrder
# Added test for getAllApplicableServices
                
> Extending Stack definition to remove duplication in stack metadata info.
> ------------------------------------------------------------------------
>
>                 Key: AMBARI-2819
>                 URL: https://issues.apache.org/jira/browse/AMBARI-2819
>             Project: Ambari
>          Issue Type: Improvement
>          Components: controller
>            Reporter: Siddharth Wagle
>            Assignee: Siddharth Wagle
>         Attachments: AMBARI-2819.patch
>
>
> The idea is to allow extending a stack definition and overriding some of its values.
> Current stack definition structure of files and directories:
> {noformat}
> |_ stacks
>    |_ <dist_name>
>       |_ <version_number>
>          metainfo.xml
>          |_ repos
>              repoinfo.xml
>          |_ services
>             |_ <service_name>
>                metainfo.xml
>                |_ configuration
>                   configuration files
> {noformat}
> We introduce extends element at the top level (stack version level) that links to the
parent stack definition for this stack version.
> *Rules of extension*: 
> 1.    All of the parent stack services are automatically a part of the child stack unless
explicitly excluded.
> 2.    Only one parent stack can be extended by the child stack.
> 3.    <stacks>.<dist_name>.<repos>.repoinfo.xml, will not be overridden
> 4.    All service configurations unless explicitly excluded are a part of the child service
definition.
> *1.  Extending stack definition*
> File: <stacks>.<dist_name>.<version_number>.metainfo.xml
> E.g.: /stacks/HDP/1.3.1/metainfo.xml
>  
> {noformat}
> <metainfo>
>     <versions>
>         <upgrade>1.2.0</upgrade>
>     </versions>
>     <active>true</active>
>     <extends>1.3.0</extends>
> </metainfo>
> {noformat}
> *2.  Extending service definition*
> <stacks>.<dist_name>.<version_number>.<service_name>.metainfo.xml
> E.g.: /stacks/HDP/1.2.1/services/HDFS/metainfo.xml
> {noformat}
> <metainfo>
>     <user>root</user>
>     <comment>Apache Hadoop Distributed File System</comment>
>     <version>1.1.2</version>
>     <deleted>false<deleted>
> </metainfo>
> {noformat}
> *2.1 Extending component definition*
> Components can be added or deleted from the stack.
> {noformat}
> <component>
>     <name>YARN_CLIENT</name>
>     <category>CLIENT</category>
>     <deleted>true</deleted>
> </component>
> {noformat}
> *3.  Extending service configurations*
> File: <stacks>.<dist_name>.<version_number>.<service_name>.<configuration>.configuration_file
> E.g.: /stacks/HDP/1.3.1/services/HDFS/configuration/hdfs-site.xml
> {noformat}
> <configuration>
>   <property>
>       <name>dfs.name.dir</name>
>       <deleted>true</deleted>
>   </property>
> </configuration>
> {noformat}
> *Notes*: 
> The same property can disappear and reappear in an extension graph.
> {noformat}
> 1.3.0 ----------------> 1.3.1 ----------------> 1.3.2 ----------------> 1.3.5
> a = b                   a = c                                           a = c
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message