[
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 redefine a 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 or
dependency group.
We will support two options(policies) for stack extension:
- extend parent's RCO, appending dependencies specified at child's RCO to
corresponding groups 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.
If role_command_order.json file is absent at stack, parent's file is used.
Policy selection is performed via "rco-policy" key at role_command_order.json
file
{code}
{
"_comment" : "rco-policy defines how do we build RCO when stack extension is
performed. Possible values are: append (add child's dependencies to",
"_comment" : "parent's RCO) and replace (ignore parent's RCO)",
"rco-policy" : "append",
"_comment" : "Record format:",
"_comment" : "blockedRole-blockedCommand: [blockerRole1-blockerCommand1,
blockerRole2-blockerCommand2, ...]",
"general_deps" : {
"_comment" : "dependencies for all cases",
"NAGIOS_SERVER-INSTALL" : ["HIVE_CLIENT-INSTALL", "HCAT-INSTALL",
"MAPREDUCE_CLIENT-INSTALL", "OOZIE_CLIENT-INSTALL"],
"HBASE_MASTER-START": ["ZOOKEEPER_SERVER-START"],
{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 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 redefine a 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 or
dependency group.
We will support two options(policies) for stack extension:
- extend parent's RCO, appending dependencies specified at child's RCO to
corresponding groups 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 performed via rco-policy key.
If role_command_order.json file is absent at stack, parent's file is used.
Or we may have "rco-policy" setting at role_command_order.json file (instead of
stack metainfo.xml)
{code}
{
"_comment" : "rco-policy defines how do we build RCO when stack extension is
performed. Possible values are: append (add child's dependencies to",
"_comment" : "parent's RCO) and replace (ignore parent's RCO)",
"rco-policy" : "append",
"_comment" : "Record format:",
"_comment" : "blockedRole-blockedCommand: [blockerRole1-blockerCommand1,
blockerRole2-blockerCommand2, ...]",
"general_deps" : {
"_comment" : "dependencies for all cases",
"NAGIOS_SERVER-INSTALL" : ["HIVE_CLIENT-INSTALL", "HCAT-INSTALL",
"MAPREDUCE_CLIENT-INSTALL", "OOZIE_CLIENT-INSTALL"],
"HBASE_MASTER-START": ["ZOOKEEPER_SERVER-START"],
{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
> redefine a 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 or dependency group.
> We will support two options(policies) for stack extension:
> - extend parent's RCO, appending dependencies specified at child's RCO to
> corresponding groups 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.
> If role_command_order.json file is absent at stack, parent's file is used.
> Policy selection is performed via "rco-policy" key at role_command_order.json
> file
> {code}
> {
> "_comment" : "rco-policy defines how do we build RCO when stack extension
> is performed. Possible values are: append (add child's dependencies to",
> "_comment" : "parent's RCO) and replace (ignore parent's RCO)",
> "rco-policy" : "append",
> "_comment" : "Record format:",
> "_comment" : "blockedRole-blockedCommand: [blockerRole1-blockerCommand1,
> blockerRole2-blockerCommand2, ...]",
> "general_deps" : {
> "_comment" : "dependencies for all cases",
> "NAGIOS_SERVER-INSTALL" : ["HIVE_CLIENT-INSTALL", "HCAT-INSTALL",
> "MAPREDUCE_CLIENT-INSTALL", "OOZIE_CLIENT-INSTALL"],
> "HBASE_MASTER-START": ["ZOOKEEPER_SERVER-START"],
> {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)
