ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nate Cole (JIRA)" <>
Subject [jira] [Commented] (AMBARI-4358) Add stack extension support for pluggable services
Date Tue, 21 Jan 2014 13:23:21 GMT


Nate Cole commented on AMBARI-4358:

+1 to Sid and symlinks - using symlinks will become troublesome on the (future) day when we
decide to run agent's on systems that don't support symlinks.  It should be possible to instruct
which stack version is used, as we currently determine that via command['hostLevelParams']['stack_version'].
 Possibly send in a "command_stack_version" attribute instead, where we have already resolved
in Ambari which version is the right one.

> Add stack extension support for pluggable services
> --------------------------------------------------
>                 Key: AMBARI-4358
>                 URL:
>             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 ->
> - 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

View raw message