incubator-ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sumit Mohanty (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-1426) Create cluster level Custom Action support
Date Tue, 17 Sep 2013 20:29:52 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sumit Mohanty updated AMBARI-1426:
----------------------------------

    Description: 
While managing an HDP cluster, the admin may need to execute custom scripts etc. to perform
house-keeping operations. Ambari support for smoke test can be viewed as one such operation,
which has a first class support in Ambari. It is conceivable that in future releases several
such operations need to be supported by Ambari. Some such requirements are:
* Validate Kerberos settings
* Perform metadata check/backup (e.g. fsck) prior to upgrade
* Dump the list of datanodes

Rather than designing each of these capabilities in a one-off fashion, it is useful to develop
an infrastructure to execute such operations and then define new operations based on the infrastructure.


h3. Custom Action Definition
A custom action is a python (_can be extended to other scripting language including puppet_)
script that can be executed to perform any management activity on a cluster. The relevant
aspects of a custom action are:
*Alias*: A friendly name of a custom action. E.g. “Validate_Kerberos_Setting”
*Definition*: The definition of the custom action. This is essentially a script that will
get executed.
*Input*: A set of name-value pairs that are the input to the script. E.g. “principal=abc@abc.com”.
*Context*: The default context that is available to all custom actions. The context will include.
* Cluster name
* Host name
* Service name
* Component name
*Target*: The target node(s)/host(s), where the custom action will be executed. Optionally,
an action may explicitly specify the component on which it can be executed – e.g. NAMENODE,
in which case a host that has the component mapped will be randomly selected. 
*MaxExecutionTime*: The maximum execution time allowed for these class of custom actions.
Ambari will enforce an absolution maximum time limit for all custom actions


  was:
While managing an HDP cluster, the admin may need to execute custom scripts etc. to perform
house-keeping operations. Ambari support for smoke test can be viewed as one such operation,
which has a first class support in Ambari. It is conceivable that in future releases several
such operations need to be supported by Ambari. Some such requirements are:
* Validate Kerberos settings
* Perform metadata check/backup (e.g. fsck) prior to upgrade
* Dump the list of datanodes

Rather than designing each of these capabilities in a one-off fashion, it is useful to develop
an infrastructure to execute such operations and then define new operations based on the infrastructure.



    
> Create cluster level Custom Action support
> ------------------------------------------
>
>                 Key: AMBARI-1426
>                 URL: https://issues.apache.org/jira/browse/AMBARI-1426
>             Project: Ambari
>          Issue Type: Bug
>    Affects Versions: 1.2.3
>            Reporter: Sumit Mohanty
>            Assignee: Sumit Mohanty
>             Fix For: 1.3.0
>
>
> While managing an HDP cluster, the admin may need to execute custom scripts etc. to perform
house-keeping operations. Ambari support for smoke test can be viewed as one such operation,
which has a first class support in Ambari. It is conceivable that in future releases several
such operations need to be supported by Ambari. Some such requirements are:
> * Validate Kerberos settings
> * Perform metadata check/backup (e.g. fsck) prior to upgrade
> * Dump the list of datanodes
> Rather than designing each of these capabilities in a one-off fashion, it is useful to
develop an infrastructure to execute such operations and then define new operations based
on the infrastructure. 
> h3. Custom Action Definition
> A custom action is a python (_can be extended to other scripting language including puppet_)
script that can be executed to perform any management activity on a cluster. The relevant
aspects of a custom action are:
> *Alias*: A friendly name of a custom action. E.g. “Validate_Kerberos_Setting”
> *Definition*: The definition of the custom action. This is essentially a script that
will get executed.
> *Input*: A set of name-value pairs that are the input to the script. E.g. “principal=abc@abc.com”.
> *Context*: The default context that is available to all custom actions. The context will
include.
> * Cluster name
> * Host name
> * Service name
> * Component name
> *Target*: The target node(s)/host(s), where the custom action will be executed. Optionally,
an action may explicitly specify the component on which it can be executed – e.g. NAMENODE,
in which case a host that has the component mapped will be randomly selected. 
> *MaxExecutionTime*: The maximum execution time allowed for these class of custom actions.
Ambari will enforce an absolution maximum time limit for all custom actions

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message