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