[
https://issues.apache.org/jira/browse/AMBARI-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lysnichenko updated AMBARI-4358:
---------------------------------------
Description:
h1. Proposal on inheritance rules for schema ver 2.0 service metainfo
h2. Package and repository information
Per-stack repository information will not be subject of stack extension (just
as it is done now). At the same time, if osSpecifics section (containing
per-service repo and package descriptions) is present at metainfo of inherited
service, it completely overrides appropriate information of a parent service.
Deletion of inherited osSpecifics section is not possible because doing that
makes no sense (service will not be able to install).
h2. Command scripts and custom commands
- Command script definition at child overrides parent's command script
definition.
- Custom command script definition in child overrides parent's custom command
script definition with the same command name.
h2. Script files and templates
Metainfo file structure for old-style (puppet) services did not contain script
files and templates. At the same time, it would be definitely nice to avoid
having a lot of file duplicates at project source. So the proposal is to have a
separate python script, that will:
- read service and stack metainfo for all stacks and build inheritance tree
- create appropriate symlinks for service folders where needed
(2.1.1/services/HDFS -> 2.0.6/services/HDFS)
- create appropriate symlinks for services that have no "package" folder
(child's "package" folder -> parent's "package" folder). Package folder
contains all scripts and templates.
- create symlinks on parent's hook dir for stacks that have no own hook dir
- create symlinks on role_command_order.json file for stacks that have no own
hook dir
This script will be triggered when running "ambari-server setup" command. Also,
as far as agents have no ability to download stack files from the server yet,
this script will be packaged to agent's rpm as well and launched at a
post-install hook.
This approach should let us keep agent-side logic of filename resolution
simple. Later, when agent will be downloading scripts from the server instead
of having them packaged to rpm, agent will have multiple file duplicates in
cache (but I don't see any problem here).
h2. Pre- and postcommand hooks
Let's assume that at 2.1.1 stack we have ZK inherited from 2.0.6 stack. Then
when running any command for ZK, appropriate hooks (if any) will be launched
from hook dir of 2.1.1 stack. At the same time, if stack has no it's own hooks
dir, it will inherit parent's one. This will be done using symlinks by the
script, described at "Script files and templates" chapter.
With proposed stack extension rules, child stack metainfo should be lightweight
enough in cases of minor changes (like adjusting repository information or
package names).
was:
Primary scope for this jira is
/org/apache/ambari/server/api/util/StackExtensionHelper.java
determine what may be overriden when extending stack with pluggable services
allow (per-service) repository overriding when extending stack
add configDependencies support for V2 service metainfo
> Add stack extension support for pluggable services
> --------------------------------------------------
>
> Key: AMBARI-4358
> URL: https://issues.apache.org/jira/browse/AMBARI-4358
> Project: Ambari
> Issue Type: Improvement
> Components: controller
> Affects Versions: 1.5.0
> Reporter: Dmitry Lysnichenko
> Assignee: Dmitry Lysnichenko
> Fix For: 1.5.0
>
>
> h1. Proposal on inheritance rules for schema ver 2.0 service metainfo
> h2. Package and repository information
> Per-stack repository information will not be subject of stack extension (just
> as it is done now). At the same time, if osSpecifics section (containing
> per-service repo and package descriptions) is present at metainfo of
> inherited service, it completely overrides appropriate information of a
> parent service. Deletion of inherited osSpecifics section is not possible
> because doing that makes no sense (service will not be able to install).
> h2. Command scripts and custom commands
> - Command script definition at child overrides parent's command script
> definition.
> - Custom command script definition in child overrides parent's custom command
> script definition with the same command name.
> h2. Script files and templates
> Metainfo file structure for old-style (puppet) services did not contain
> script files and templates. At the same time, it would be definitely nice to
> avoid having a lot of file duplicates at project source. So the proposal is
> to have a separate python script, that will:
> - read service and stack metainfo for all stacks and build inheritance tree
> - create appropriate symlinks for service folders where needed
> (2.1.1/services/HDFS -> 2.0.6/services/HDFS)
> - create appropriate symlinks for services that have no "package" folder
> (child's "package" folder -> parent's "package" folder). Package folder
> contains all scripts and templates.
> - create symlinks on parent's hook dir for stacks that have no own hook dir
> - create symlinks on role_command_order.json file for stacks that have no own
> hook dir
> This script will be triggered when running "ambari-server setup" command.
> Also, as far as agents have no ability to download stack files from the
> server yet, this script will be packaged to agent's rpm as well and launched
> at a post-install hook.
> This approach should let us keep agent-side logic of filename resolution
> simple. Later, when agent will be downloading scripts from the server instead
> of having them packaged to rpm, agent will have multiple file duplicates in
> cache (but I don't see any problem here).
> h2. Pre- and postcommand hooks
> Let's assume that at 2.1.1 stack we have ZK inherited from 2.0.6 stack. Then
> when running any command for ZK, appropriate hooks (if any) will be launched
> from hook dir of 2.1.1 stack. At the same time, if stack has no it's own
> hooks dir, it will inherit parent's one. This will be done using symlinks by
> the script, described at "Script files and templates" chapter.
> With proposed stack extension rules, child stack metainfo should be
> lightweight enough in cases of minor changes (like adjusting repository
> information or package names).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
