Sumit Mohanty created AMBARI-3608:
-------------------------------------
Summary: Custom Action: Add support for Custom Action Definition
Key: AMBARI-3608
URL: https://issues.apache.org/jira/browse/AMBARI-3608
Project: Ambari
Issue Type: Bug
Components: controller
Affects Versions: 1.4.2
Reporter: Sumit Mohanty
Assignee: Sumit Mohanty
Fix For: 1.5.0
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. Validate_Kerberos_Setting.py).
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:
NAMENODE
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
http://c6401.ambari.apache.org:8080/api/v1/action_definitions
{
"href" : "http://c6401.ambari.apache.org:8080/api/v1/action_definitions";,
"items" : [
{
"href" :
"http://c6401.ambari.apache.org:8080/api/v1/action_definitions/hdfs_rebalance_blocks";,
"ActionDefinitions" : {
"action_name" : "hdfs_rebalance_blocks"
}
}
]
}
curl -u admin:admin -i
http://c6401.ambari.apache.org:8080/api/v1/action_definitions/hdfs_rebalance_blocks
{
"href" :
"http://c6401.ambari.apache.org:8080/api/v1/action_definitions/hdfs_rebalance_blocks";,
"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
(v6.1#6144)
