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 Tue, 10 Sep 2013 17:07:52 GMT

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

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

    Description: 
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}



  was:
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}

*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}




    
> 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