incubator-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] [Commented] (AMBARI-3548) Changes to stacks definitions to allow custom services support (needed by an ambari-agent)
Date Fri, 18 Oct 2013 15:40:46 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799210#comment-13799210
] 

Dmitry Lysnichenko commented on AMBARI-3548:
--------------------------------------------

service_metainfo_changes.patch is a separate diff for ambari-server/src/main/resources/stacks/HDP/2.0.6/services/HBASE/metainfo.xml
file

h2. Here is a filesystem structure for a custom service:
{code}
ambari-server/src/main/resources/stacks/HDP/2.0._/services/HBASE
├── configuration
│   ├── global.xml
│   ├── hbase-policy.xml
│   └── hbase-site.xml
├── metainfo.xml
├── scripts
│   ├── hbase_client.py  
│   ├── hbase_master.py // hbase_* are per-component script files
│   ├── hbase.py  // Per-service script file
│   └── hbase_regionserver.py
└── templates
{code}

Patch brings back-compatible changes to stack definitions and Execution command format. I've
decided to avoid adding new command (sub)type because ExecutionCommand is intensively used
across the code. Patch adds additional fields to ExecutionCommand according to Custom Services
design doc. Some info in these fields duplicates old ExecutionCommand fields, but the latter
fields are marked for removal when we complete transition to a new design.

h2. Limitations:
As of now, Custom Services does not support overriding repository information via stack extensions
(at methods org.apache.ambari.server.api.util.StackExtensionHelper#mergeServices and org.apache.ambari.server.api.util.StackExtensionHelper#populateServicesForStack).
Probably need a separate jira for that.

Per-service repository information probably should be defined in a separate file (repoinfo.xml
inside service folder), but it would take more time/server changes to implement and will be
probably done later as a separate jira.

also probably need a separate jira for per-component host list generation (current implementation
may be hardcoded, did not check)

h2. Changes to  Execution Command format
-'commandParams' map now contains is_custom field (true if execution command is issued for
a custom service)
-'commandParams' map 'command_timeout' field (as of now, it is only initialised for execution
commands for custom services, wider usage will be introduced by BUG-9162)
-added to 'hostLevelParams' map 'stack_id' field (like 'HDP-2.0.5') (зроблено)
-added to 'hostLevelParams' map optional 'custom_repo_info' field (with repository list for
custom services).
-added to 'hostLevelParams' map optional 'os_type' field


> Changes to stacks definitions to allow custom services support (needed by an ambari-agent)
> ------------------------------------------------------------------------------------------
>
>                 Key: AMBARI-3548
>                 URL: https://issues.apache.org/jira/browse/AMBARI-3548
>             Project: Ambari
>          Issue Type: Bug
>          Components: controller
>    Affects Versions: 1.5.0
>            Reporter: Dmitry Lysnichenko
>            Assignee: Dmitry Lysnichenko
>             Fix For: 1.5.0
>
>         Attachments: AMBARI-2036-preview.patch, service_metainfo_changes.patch
>
>
> Stack definitions for custom services should contain fields:
> - service metadata
> -- list of repositories
> - component metadata should contain fields:
> -- scriptType (possible values: "python", "puppet")
> -- taskTimeout (per-component value)
> Except metadata files, custom service directory should contain:
> - script directory that contains separate python files for components (e.g. namenode.py,
datanode.py etc.) and service.py file.
> - a separate directory for templates



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message