Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Mon, 20 Jan 2014 21:35:34 +0000 (UTC)
From: "Dmitry Lysnichenko (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12689864.1390247388685.36374.1390253734383@arcas>
In-Reply-To: <JIRA.12689864.1390247388685@arcas>
References: <JIRA.12689864.1390247388685@arcas>
Subject: [jira] [Updated] (AMBARI-4358) Add stack extension support for
 pluggable services
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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
Stack 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 create 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:
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
Stack 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 create 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).


> 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
> Stack 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 create 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)