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

Dmitry Lysnichenko updated AMBARI-4504:
---------------------------------------

    Description: 
h1. Implementation proposal
The most common use case for stack extension is adding new services or slightly 
modifying existing ones. So typically child's RCO file should look like a diff 
("What dependencies should we add to parent's RCO to support newly added 
services?"). For  more complex situations (when changes that are introduced by 
child stack fundamentally change RCO), it makes sense to have complete RCO file 
instead of inheritance. That's why I propose to keep RCO file syntax simple and 
don't implement support of deleting/modifying specific dependency. 
So we will support two options(policies) for stack extension:
- extend parent's RCO, appending dependencies specified at child's RCO to 
corresponding group of parent's RCO (default). For every dependency group, 
parent's set of dependencies and child's set of dependencies are merged.
- completely override (replace) parent's RCO by child's RCO file.
Policy selection is done at stack metainfo.xml.
{code}
<metainfo>
  <versions>
    <active>true</active>
  </versions>
  <extends>2.0.5</extends>

  <rco-policy>append</rco-policy>
  <!-- or -->
  <rco-policy>replace</rco-policy>
</metainfo>
{code}

Also, I'll add to every role_command_json file at inherited stacks a comment 
like:
{code}
This file appends role command order dependencies to ones defined at parent 
stack. To change this behaviour, please consult the documentation on rco-policy 
element of a stack metainfo.xml file.
{code}

Also, in debug mode, an effective RCO will be printed to log to simplify 
troubleshooting.

  was:
h1. Implementation proposal
The most common use case for stack extension is adding new services or slightly 
modifying existing ones. So typically it should look like diff ("What 
dependencies should we add to parent's RCO to support newly added services?"). 
For  more complex situations (when changes that are introduced by child stack 
fundamentally change RCO), it makes sense to have complete RCO file instead of 
inheritance. That's why I propose to keep RCO file syntax simple and don't 
implement support of deleting/modifying specific dependency. 
So we will support two options(policies) for stack extension:
- extend parent's RCO, appending dependencies specified at child's RCO to 
corresponding group of parent's RCO (default). For every dependency group, 
parent's set of dependencies and child's set of dependencies are merged.
- completely override (replace) parent's RCO by child's RCO file.
Policy selection is done at stack metainfo.xml.
{code}
<metainfo>
  <versions>
    <active>true</active>
  </versions>
  <extends>2.0.5</extends>

  <rco-policy>append</rco-policy>
  <!-- or -->
  <rco-policy>replace</rco-policy>
</metainfo>
{code}

Also, I'll add to every role_command_json file at inherited stacks a comment 
like:
{code}
This file appends role command order dependencies to ones defined at parent 
stack. To change this behaviour, please consult the documentation on rco-policy 
element of a stack metainfo.xml file.
{code}

Also, in debug mode, an effective RCO will be printed to log to simplify 
troubleshooting.


> role_command_order is not inherited from the parent stack
> ---------------------------------------------------------
>
>                 Key: AMBARI-4504
>                 URL: https://issues.apache.org/jira/browse/AMBARI-4504
>             Project: Ambari
>          Issue Type: Task
>          Components: controller, test
>    Affects Versions: 1.5.0
>            Reporter: Dmitry Lysnichenko
>            Assignee: Dmitry Lysnichenko
>             Fix For: 1.5.0
>
>
> h1. Implementation proposal
> The most common use case for stack extension is adding new services or 
> slightly modifying existing ones. So typically child's RCO file should look 
> like a diff ("What dependencies should we add to parent's RCO to support 
> newly added services?"). For  more complex situations (when changes that are 
> introduced by child stack fundamentally change RCO), it makes sense to have 
> complete RCO file instead of inheritance. That's why I propose to keep RCO 
> file syntax simple and don't implement support of deleting/modifying specific 
> dependency. 
> So we will support two options(policies) for stack extension:
> - extend parent's RCO, appending dependencies specified at child's RCO to 
> corresponding group of parent's RCO (default). For every dependency group, 
> parent's set of dependencies and child's set of dependencies are merged.
> - completely override (replace) parent's RCO by child's RCO file.
> Policy selection is done at stack metainfo.xml.
> {code}
> <metainfo>
>   <versions>
>     <active>true</active>
>   </versions>
>   <extends>2.0.5</extends>
>   <rco-policy>append</rco-policy>
>   <!-- or -->
>   <rco-policy>replace</rco-policy>
> </metainfo>
> {code}
> Also, I'll add to every role_command_json file at inherited stacks a comment 
> like:
> {code}
> This file appends role command order dependencies to ones defined at parent 
> stack. To change this behaviour, please consult the documentation on 
> rco-policy element of a stack metainfo.xml file.
> {code}
> Also, in debug mode, an effective RCO will be printed to log to simplify 
> troubleshooting.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to