incubator-ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sumit Mohanty (JIRA)" <>
Subject [jira] [Commented] (AMBARI-3608) Custom Action: Add support for Custom Action Definition
Date Sat, 02 Nov 2013 15:14:21 GMT


Sumit Mohanty commented on AMBARI-3608:

In addition to incorporating the feedback, the patch also converts existing actions (*_SERVICE_CHECK
and DECOMMISSION_DATANODE) into commands. Currently, the commands are hard-coded in AMC. When
agent support for service specification is complete we modify these commands to be declarative.

> Custom Action: Add support for Custom Action Definition
> -------------------------------------------------------
>                 Key: AMBARI-3608
>                 URL:
>             Project: Ambari
>          Issue Type: Sub-task
>          Components: controller
>    Affects Versions: 1.4.2
>            Reporter: Sumit Mohanty
>            Assignee: Sumit Mohanty
>             Fix For: 1.5.0
>         Attachments: AMBARI-3608.patch
> A custom action has a name, which must be unique across all actions. The name must be
fairly descriptive.  It is expected that a script (currently, python) with name <Name>.py
is also available (e.g.
> Sample *Name*: Validate_Kerberos_Setting
> Action is also associated with a description that provides a short summary of what the
action does.
> Sample *Description*: Validates Kerberos setting to ensure that host-components can communicate
with each other.
> An action can be of one of the following types:
> System: Actions that are available with Ambari.
> System_Disabled: Disabled by Ambari due to high failure rate.
> User: Actions that are added by the user.
> Currently, all actions are system actions.
> Sample *Type*: SYSTEM
> Action defines the expected inputs by name. When invoking, the inputs are provided as
name-value pairs where the name must match allowed input parameter names.
> Sample *Inputs*: 
>     principal: The identity whose access is being verified
>     keytab: The keytab associated with the principal.
> Actions can optionally define the target host where it should be executed. If the target
is not specified then it is expected as an input when creating an action. If the target is
specified then the server finds a single host that matches the requirements and executes the
action on that host.
> Additionally, Action definition can specify the target Service and Component which constrainst
the hosts on which the action can be executed. Essentially, the host must have the Service
and Component deployed. It is possible for the action executon to provide a set of target
hosts. It is expected that the hosts must have the target component deployed. An empty target
means that the action can be executed on an arbitrary host. TargetType refers to whether the
action should be executed on all hosts that match the requirement or any one host, etc.
> TargetService: 
>     HDFS
> TargetComponent: 
> TargetType: 
>     ANY
> Action can optionally specify a custom value for max timeout. This value, if less than
Ambari wide action timeout, overrides the timeout value when executing the action. Timeout
is applied on a per host basis and is not an aggregate across execution on all hosts.
> DefaultTimeout: 
>     180
> Sample API calls:
> {code}
> curl -u admin:admin -i
> {
>   "href" : "",
>   "items" : [
>     {
>       "href" : "",
>       "ActionDefinitions" : {
>         "action_name" : "hdfs_rebalance_blocks"
>       }
>     }
>   ]
> }
> curl -u admin:admin -i
> {
>   "href" : "",
>   "ActionDefinitions" : {
>     "action_name" : "hdfs_rebalance_blocks",
>     "action_type" : "SYSTEM",
>     "default_timeout" : "590",
>     "description" : "HDFS, Rebalance Blocks",
>     "inputs" : null,
>     "target_component" : "NAMENODE",
>     "target_host" : "",
>     "target_service" : "HDFS"
>   }
> }
> {code}

This message was sent by Atlassian JIRA

View raw message