ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Lysnichenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-4358) Add stack extension support for pluggable services
Date Tue, 28 Jan 2014 20:46:38 GMT

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

Dmitry Lysnichenko updated AMBARI-4358:
---------------------------------------

    Attachment: AMBARI-4358_preview.patch

I've attached a (non-final) patch. It seems to work, but is not well-tested yet and is missing
some unit tests. [~aonishuk], you may use this patch for now for porting puppet stacks to
python.

> 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
>
>         Attachments: AMBARI-4358_preview.patch
>
>
> 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)

Mime
View raw message