[jira] [Commented] (AMBARI-3548) Changes to stacks definitions to allow custom services support (needed by an ambari-agent)

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

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