[jira] [Commented] (AMBARI-4358) Add stack extension support for pluggable services

["Siddharth Wagle (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMBARI-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876982#comment-13876982 ] 

Siddharth Wagle commented on AMBARI-4358:
-----------------------------------------

[~dmitriusan] Some questions/comments:

- When would the scripts that create symlinks run ?
- How would upgrade scenario be handled with existing symlinks?
- Is there an alternative to creating symlinks which could be fragile: meaning an accidental symlink delete leads to broken agent?
- Is it possible to consider an approach where scripts, hooks and templates are written for a service say HDFS without tie up to a specific stack version and then in the definition of a stack say 2.1.1, we declaratively pin point with script to use for that version. This way it becomes easy to develop a inheritance chain of python classes and unit test changes as stack is added.

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