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