[
https://issues.apache.org/jira/browse/AMBARI-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lysnichenko updated AMBARI-4358:
---------------------------------------
Description:
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 (solving authentification issues)
- stack cache management (downloading stacks from server to an agent on first
use, 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).
was:
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)
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 from the server a list
of stacks to look in. We look up this list of stacks (starting from the child)
for every file we are running via PythonExecutor (hook script, command script,
template file). 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 server to the agent (solving authentification issues)
- stack cache management (downloading stacks from server to an agent on first
use, 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).
> 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 (solving authentification issues)
> - stack cache management (downloading stacks from server to an agent on
> first use, 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).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
