[AMBARI-3608] Custom Action: Add support for Custom Action Definition

• Type: Sub-task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.4.2
• Fix Version/s: 1.5.0
• Component/s: ambari-server
• Assignee: Sumit Mohanty
• Reporter: Sumit Mohanty
• Created: 28/Oct/13 21:13
• Updated: 31/Dec/13 15:33
• Resolved: 09/Nov/13 00:19

Description

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:

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"
  }
}

Issue Links

• relates to: AMBARI-3524 Set up generic puppet module architecture to manage both HDP and CDH (and Apache?) stacks