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

["Dmitry Lysnichenko (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMBARI-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitry Lysnichenko resolved AMBARI-4358.
----------------------------------------

    Resolution: Fixed

committed to trunk

> 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 a 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. Hooks, script files and templates
> We allow reusing python scripts and templates from parent stack(s). The limitation is that only full "package" directory may be overridden. Implementation of resolving hooks is pretty similar.
> How it is done: 
> When reading stacks on startup, ambari-server determines what service folders/"package" folders/"hooks" folders are missing (inherited from parent) and appropriately adjusts ServiceInfo. When sending execution commands, server populates "service_metadata_folder" and "hooks_folder" variables (located at commandParams section) with appropriate paths.
> h2. To be done in a separate jira(s)
> A complete list of stack extension functionality that is not in scope of current jira (please feel free to append):
> - per-file overrides for scripts and templates. We get a list of stacks (search paths) from the server. We look up for every file we are running via PythonExecutor (hook script, command script, template file) at this list of stacks (starting from the child stack) . Files that are imported by scrips using "import" statements, can not be overridden.
> - (maybe) packaging files that will be downloaded by an agent to tar files. So for every stack, there will exist few "package.tar" files (one per service) and one "hooks.tar" file (one per stack). Every file is a separate download unit.
> - exposing files from the server to an agent (resolving authentification issues)
> - stack cache management  (downloading stacks from the server to an agent on first use and cache invalidation)
> With proposed stack extension rules, child stack metainfo should be lightweight enough in cases of minor changes (like adjusting repository information or package names, or editing file templates).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)