ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Lysnichenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-4504) role_command_order is not inherited from the parent stack
Date Mon, 03 Feb 2014 14:48:08 GMT

     [ 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
Usual use case for stack extension is adding new services. 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.

  was:
h1. Implementation proposal
Usual use case for stack extension is adding new services. 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 introduces 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
> Usual use case for stack extension is adding new services. 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.



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

Mime
View raw message