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-4358) Add stack extension support for pluggable services
Date Mon, 20 Jan 2014 21:29:20 GMT

     [ 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)

Mime
View raw message