actions
Action is an entity used to describe an operation on an ADCM object. This action is ultimately the launch of an Ansible playbook with certain parameters under certain conditions.
An action may consist of one or more subjobs.
The sequence of executed subjobs can be defined in one of the following ways:
-
statically, using the scripts property;
-
dynamically, using the scripts_template property.
If you need to specify parameters that a user should enter before running an action, use one of the following properties:
-
config — static definition of the parameter list;
-
config_template — dynamic definition of the parameter list.
For more complex action configuration scenarios, use the wizard_template property.
Other properties that can be used to define actions are listed below.
---
- type: cluster
name: control
version: 1
description: "Monitoring and Control Software"
actions:
install:
display_name: "Install Monitor Server"
description: |
By clicking this button, you install monitoring and controlling server ...
allow_to_terminate: true
scripts:
- name: install_server
script_type: ansible
script: ansible/site.yaml
params:
ansible_tags: install
jinja2_native: true
states:
available:
- created
on_success: installed
on_fail: created
config:
quorum:
type: integerallow_for_action_host_group
An action may have an optional boolean property allow_for_action_host_group, which controls whether the action can be executed for a host group. The default value is false. If allow_for_action_host_group is set to true, the action can be executed for host groups.
actions:
install:
display_name: "Install"
scripts:
- name: install_cluster
script_type: ansible
script: ansible/site.yaml
allow_for_action_host_group: trueRestrictions on using the allow_for_action_host_group property:
-
Actions that are part of an upgrade operation (see Upgrade a cluster to a new ADP version) cannot be executed for a host group.
-
The simultaneous use of this property and the host_action property is not supported.
allow_in_maintenance_mode
An action may have an optional boolean property allow_in_maintenance_mode that controls whether the action is permitted to run in maintenance mode. The default value is false. When both allow_in_maintenance_mode and allow_maintenance_mode are set to true, the action is allowed to run even if the object or any of its hosts is in maintenance mode.
allow_to_terminate
An action may have an optional boolean property allow_to_terminate that controls whether the action and its jobs can be forcibly stopped. The default value is false. If allow_to_terminate is set to true, the user can interrupt the execution of the action. In this case:
-
When a job is interrupted, the currently running subjob completes its execution by interrupting the Ansible playbook, after which the job is terminated.
-
When a subjob is interrupted (using the
icon), the execution of the Ansible playbook is interrupted and the next subjob is started without terminating the job.
In all other cases, stopping an action is not allowed.
The allow_to_terminate property applies to all subjobs that are part of the action. When one of these subjobs is interrupted, the execution of the action continues with the next subjob. Therefore, specifying the allow_to_terminate property for an action is equivalent to specifying this property for all of its subjobs.
config
The config property defines a static list of configuration parameters. When an action is executed in the ADCM web interface, the values of these parameters are requested from the user before the action starts.
To use parameters entered by the user in an Ansible playbook, you need to reference them by their full path.
Consider the following configuration:
actions:
install:
display_name: "Install"
scripts:
- name: install_cluster
script_type: ansible
script: ansible/site.yaml
config:
- name: restart_after_install
type: boolean
- name: sudo_password
type: passwordTo access parameters entered by the user in an Ansible playbook, you can reference them in the inventory context as follows:
"{{ job.config.restart_after_install }}"
"{{ job.config.sudo_password }}"where job.config is the path to the specified parameters.
The config property is used for static configuration parameters that are displayed in the same way each time the action is executed. If you need to work with dynamic configuration parameters, use the config_template property.
config_template
An action may have an optional config_template property. This property points to a file in the Jinja format.
The config_template property is used to work with dynamic configuration parameters. Here, "dynamic" means that certain parameters can be shown or hidden based on specific conditions — in other words, depending on the cluster topology (for example, depending on whether a particular service has been added to the cluster). When action metadata is retrieved (using a GET request to the API), a Jinja file (Jinja2 template) is rendered. During template rendering, a context corresponding to the inventory file is created, excluding changes made by config groups, as well as variables and facts generated by Ansible during playbook execution.
This property cannot be used together with the config property, which is used for static configuration parameters.
---
actions:
start:
display_name: "Start"
config_template:
file:
path: scripts_jinja/cluster/restart.j2
engine:
type: jinja2
scripts_template:
file:
path: scripts_jinja/cluster/manage_install.j2
engine:
type: jinja2
states:
available:
- installedThe restart.j2 file:
- reboot_servers:
type: boolean
default: false
display_name: Reboot servers
{% if cluster.state == 'created' %}
- configure_etc:
type: boolean
default: false
display_name: Configure /etc/hosts
{% endif %}Template description format (the <config|hc|scripts|wizard>_template property) includes the following parameters:
-
file— file that is used as a template and contains the following attributes:-
path— path to the file with the .j2 or .py extension. -
entrypoint— name of thecallable()function that should be called (without specifying the package or module). This attribute is used only ifengineis set topython.
-
-
engine— file processing engine. Possible values:jinja2,python.
display_name
The display_name property specifies a short name for the action displayed to the user in the ADCM web interface.
hc_acl
An action may have an optional hc_acl property. This property is used when the action is run in the ADCM web interface, requiring the user to provide a new host-component mapping before the action starts.
actions:
expand:
display_name: "Expand"
scripts:
- name: expand_topology
script_type: ansible
script: ansible/site.yaml
states:
available: all
hc_acl:
-
service: hadoop
component: datanode
action: add
-
service: hadoop
component: server
action: removeThe hc_acl property defines the following list that controls operations for modifying the host-component mapping:
-
service— name of the service. -
component— name of the component. -
action— type of operation. Possible values:add,remove.
host_action
An action may have an optional boolean property host_action that is used to define the scope of an action at the level of an individual host. The default value is false. If host_action is set to true, the action appears in the drop-down list of actions on the Clusters → <Cluster name> → Hosts → <Host name> → Host-Components page. In this case, the action is executed for the selected host and a target group including only that host is automatically created.
It is recommended to declare an action (host_action: true) only in the context of a component as these actions allow managing a specific component on a specific host.
actions:
install:
display_name: "Install"
scripts:
- name: install_host
script_type: ansible
script: action.yaml
host_action: truemasking
masking is an alternative way to define the availability of an action in the ADCM web interface and via the API. This property allows specifying a set of basic (states) and advanced (multi_state) object states.
Use masking if you want to define action availability using advanced states, which are specified in the multi_state property.
|
IMPORTANT
The masking property is not compatible with the states property which is described below.
|
---
actions:
install:
display_name: "Install Monitor Server"
masking:
# Action will be shown if both conditions under state and multi_state are met.
state:
available:
# If the state equals to any of these, then the condition is true
- "state_value1"
- "state_value2"
unavailable:
# If you place unavailable, then no available should be there
- "state_value1"
- "state_value2"
multi_state:
available:
# If any of these multistates are present, the condition is true
- "multi_state_1"
- "multi_state_2"
unavailable:
# If you place unavailable, then no available should be there
- "multi_state_3"
- "multi_state_4"
on_fail:
state: "new_state_value"
multi_state:
set:
- "multi_state3"
unset:
- "multi_state4"
on_success:
state: "new_state_value"
multi_state:
set:
- "multi_state3"
unset:
- "multi_state4"To simplify the description of rules, you can use the any scalar which represents all possible values:
---
masking:
state:
available: "any"
unavailable: "any"
multi_state:
available: "any"
unavailable: "any"If the masking property is not set, the action is considered available for every value of the state or multi_state properties. Thus, the following options are equivalent:
---
masking:---
masking:
state:---
masking:
state:
available: "any"The options listed below are also considered equivalent:
---
masking:---
masking:
multi_state:---
masking:
multi_state:
available: "any"scripts
An action might have an optional scripts property, which is used to define the sequence of executed subjobs statically. Subjobs are executed in the same order as they are listed in the scripts property. If one of the scripts fails, the subjob execution is interrupted, and the object is moved to the state specified by on_fail.
Each subjob in the generated sequence is defined by a set of properties listed below.
actions:
install:
display_name: "Install"
scripts:
- name: prepare
display_name: Prepare to install
script_type: ansible
script: ansible/prepare.yaml
on_fail: created
- name: install
display_name: Actual install
script_type: ansible
script: ansible/install.yaml
on_fail: prepare
states:
available:
- created
- prepare
on_success: installedscripts_template
An action may have an optional scripts_template property. This property allows you to dynamically generate a list of subjobs using a Jinja2 template based on the action execution context. Each subjob in the generated sequence is defined by a set of properties listed below.
After the action is started, the Jinja2 template file is rendered to generate the sequence of subjobs. When rendering the template, the context is built from the inventory file, excluding changes from config groups, as well as the variables and facts generated by Ansible during playbook execution (including additional action details, such as values and selections made by the user during action configuration).
Template description format corresponds to the unified <config|hc|scripts|wizard>_template format.
The scripts_template property is mutually exclusive with the scripts property (static subjob generation).
actions:
add_remove_components:
display_name: "Add/remove components"
scripts_template:
file:
path: scripts_template/manage_component_scripts.j2
engine:
type: jinja2The manage_component_scripts.j2 file:
{%- if (groups['zookeeper.SERVER.add'] | length) > 0 %}
- name: zookeeper
display_name: "Zookeeper"
script_type: ansible
script: ansible/playbooks/cluster/zookeeper_install.yaml
params:
ansible_tags: repo_add, install, configure, configure_main_info, start, bootstrap
{%- endif %}
{%- if (groups['zookeeper.SERVER.remove'] | length) > 0 %}
- name: zookeeper
display_name: "Zookeeper"
script_type: ansible
script: ansible/playbooks/cluster/zookeeper_remove.yaml
params:
ansible_tags: stop, remove
{%- endif %}
- name: zookeeper
display_name: "Zookeeper"
script_type: ansible
script: ansible/playbooks/cluster/zookeeper_install.yaml
params:
ansible_tags: configurestates
An action may have an optional states property that is used to control the availability of the action and changes of states of an object during its execution. This property specifies the list of the states in which the action is allowed to run, as well as the object state after successful or failed completion of the action.
The states property defines the following states:
-
available— list of object states in which the action is available; -
on_success— object state after successful action completion; -
on_fail— object state after failed action completion.
The on_success and on_fail states are optional. If they are not specified, the object state will remain unchanged after a successful or unsuccessful completion of the action.
The states property also has two reserved values:
-
created— initial state of objects after creation; -
upgrading— state to which the cluster can be moved. In this state, certain actions, such as removing a host or service from the cluster, are not available to the user.
ui_options
The ui_options block allows you to configure how the action is displayed and executed in the ADCM web interface. When hovering over the action, a tooltip will appear showing the message specified in the disclaimer field:
actions:
install:
display_name: "Install"
scripts:
- name: install_run
script_type: ansible
script: ansible/site.yaml
ui_options:
disclaimer: "Enter your disclaimer"wizard_template
An action might have the optional wizard_template property, which is the template of the flow formed as a result of its rendering.
Unlike the config property, the wizard_template property allows you to do the following:
-
divide an action configuration into several logical steps as modal windows;
-
pass the template rendering context between steps;
-
save the states of the steps that are already provided by the user.
The wizard_template property is mutually exclusive with the following properties:
-
config, which is intended to work with static configuration parameters; -
config_template, which is intended to work with dynamic configuration parameters;
-
hc_acl, which is intended to work with the host-component mapping.
The specified property is displayed in the ADCM web interface as Wizard, which is the preparation phase of an action before its launch.
The flow is a sequence of the following elements:
-
Stages — the containers of logically related steps.
-
Steps — the minimal indivisible elements of a process performed by the user.
NOTEThe process occurs when a user clicks the action in the drop-down list of actions available to work with an object.A step can be one of the three types:
-
Configuration — a configuration filled in by the user. The configuration is dynamically generated during the rendering of the template specified in the
config_templatestatement when receiving information about a specific step. -
Operation — a job representing a set of subjobs that is launched when executing the step. The set of subjobs is dynamically generated during rendering of the template specified in the
scripts_templatestatement when executing the specific step. The example of a step of the operation type is given in the manage_install.j2 file (thecheck_kerberosstep of themanage_kerberos_stagestage). -
Mapping — a rule for a host-component mapping. The rule template and the form with default values are generated dynamically during the rendering of the template specified in the
mapping_templateproperty when receiving step information.IMPORTANTUnlike regular actions, when using Wizard, the host-component mapping is not automatically applied to the target cluster. In this case, the bundle developer should manually save the mapping specified by the user by calling hc_apply out of the Wizard process context — in other words, as part of the main job of the corresponding action.
-
A description of the Wizard visual representation in the ADCM web interface is given in the Wizard article.
Steps of the operation type provide the following options:
-
validating the action configuration parameter values entered by the user;
-
saving the action configuration parameter values entered by the user in configuration of the target object (cluster, service, or component) using the
config_applyfunction.
Each stage includes the following parameters:
-
name— unique stage name; -
display_name— name of the stage that is displayed in the ADCM web interface for the user; -
steps— sequence of steps.
The following attributes are used to describe the step:
-
Common attributes:
-
name— step name that is unique to this stage. -
display_name— Wizard step name which is intended to be used as the name of the modal window step. -
description(optional) — a text description of the step explaining its purpose to the user.
-
-
Attribute for a step of the configuration type:
config_template— template for working with dynamic configuration parameters. -
Attributes for a step of the operation type:
-
ui_options— attributes specific to UI, in particular,button_name— button name. -
scripts_template— template for dynamic generation of the subjob sequence. -
required(optional) — indicates whether the step should be executed. The default value istrue. Iffalse, the step can be completed without performing the operation.
-
-
Attribute for a step of the mapping type:
hc_template— template for defining host-component mapping rule. The template may include:-
componentandservice— names of the component and service of the corresponding object. -
operation— type of operation to be performed. Possible values:-
add— extend the set of hosts. -
remove— reduce the set of hosts.
-
-
Template description format corresponds to the unified <config|hc|scripts|wizard>_template format.
Based on the received information about an action (if wizard_template is used), a process is created.
actions:
install:
display_name: "Install"
allow_to_terminate: true
scripts_template:
file:
path: scripts_jinja/cluster/manage_install.j2
engine:
type: jinja2
wizard_template:
file:
path: wizard_jinja/manage_install.j2
engine:
type: jinja2
states:
available:
- created
- faulty_installedCreating a process, among other things, includes rendering of the file specified in wizard_template. This results in a flow. During the template rendering, the context is formed according to the inventory file, except config group changes, as well as variables and facts that Ansible generates during a playbook execution.
The wizard_jinja/manage_install.j2 file:
- name: manage_ssl_stage
display_name: "Manage SSL"
steps:
- name: configure_ssl
display_name: "Configure SSL"
description: "SSL is required for secure connection"
config_template:
file:
path: configs_jinja/manage_ssl.j2
engine:
type: jinja2
- name: manage_kerberos_stage
display_name: "Manage Kerberos"
steps:
- name: configure_kerberos
display_name: "Kerberos configuration"
config_template:
file:
path: configs_jinja/manage_kerberos.j2
engine:
type: jinja2
- name: check_kerberos
display_name: "Check configuration"
ui_options:
button_name: Check
scripts_template:
file:
path: scripts_jinja/cluster/save_config.j2
engine:
type: jinja2
{% if services.hdfs is defined and services.hdfs.state == 'created' %}
- name: hdfs_stage
display_name: "Manage HDFS"
steps:
- name: configure_hdfs
display_name: "Configure HDFS"
config_template:
file:
path: configs_jinja/manage_hdfs.j2
engine:
type: jinja2
- name: mapping
display_name: "Fill host-component mapping"
description: "Specify which hosts the service will be located on"
hc_template:
file:
path: hc_jinja/manage_hdfs_hc_step.j2
engine:
type: jinja2
- name: validate
display_name: "Validate host-component mapping"
ui_options:
button_name: Validate
scripts_template:
file:
path: scripts_jinja/validate_mapping.j2
engine:
type: jinja2
{% endif %}
{% if services.hdfs is defined and services.hdfs.state == 'created' %}
- name: hbase_stage
display_name: "Manage HBase"
steps:
- name: validate
display_name: "Validate host-component mapping"
ui_options:
button_name: Validate
scripts_template:
file:
path: scripts_jinja/validate_mapping.j2
engine:
type: jinja2
{% endif %}
- name: save_stage
display_name: "Save configuration"
steps:
- name: save_configuration
display_name: "Check configuration"
ui_options:
button_name: Check
scripts_template:
file:
path: scripts_python/cluster/check.py
entrypoint: generate_scripts
engine:
type: pythonThe manage_ssl.j2 file:
- name: ssl_config
display_name: "Enable SSL"
type: group
{% if vars.cluster.config.ssl_config.enable_ssl %}
activatable: true
{% else %}
activatable: false
{% endif %}
subs:
- name: keystore_path
display_name: "Keystore path"
type: string
default: "{{ cluster.config.ssl_default_config.keystore_path }}"
- name: keystore_password
display_name: "Keystore password"
type: passwordThe manage_kerberos.j2 file:
- name: kerberos_config
display_name: "Enable Kerberos"
type: group
{% if vars.cluster.config.kerberos_config.enable_kerberos %}
activatable: true
{% else %}
activatable: false
{% endif %}
subs:
- name: keystore_password
display_name: "Keystore password"
type: password
default: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config.keystore_password }}"The save_config.j2 file:
{% set ssl_key = "ssl_default_config/keystore_password" %}
- name: validate
display_name: "Precheck"
script_type: ansible
script: some/playbook.yaml
params:
ansible_tags:
- check
- name: state_2
display_name: "State 2"
script_type: internal
script: config_apply
params:
changes:
- object:
type: cluster
parameters:
{% if action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config.enable_ssl %}
- key: "{{ ssl_key }}"
value: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config }}"
{% endif %}
{% if action.process.stages.manage_kerberos_wizard.config.kerberos_config.enable_kerberos %}
- key: "kerberos_default_config/keystore_password"
value: "{{ action.process.stages.manage_kerberos_stage.configure_kerberos.config.kerberos_config.keystore_password }}"
{% endif %}The manage_hdfs_hc_step.j2 file:
{% raw %}
- service: hdfs
component: namenode
operation: add
- service: hdfs
component: datanode
operation: add
{% endraw %}The manage_hdfs.j2 file:
- name: dfs_data_dir
display_name: "DFS data dir"
type: string
default: {{ vars.services.hdfs.config.data_dir }}The check.py file:
def create_script_template(display_name, name, params, script, script_type):
"""Template for creating action dictionaries with consistent structure."""
return {
'display_name': display_name,
'name': name,
'params': params,
'script': script,
'script_type': script_type
}
def generate_scripts(context: dict):
cluster = context['cluster']
action = context['action']
script1 = create_script_template(
display_name='Check',
name='validate',
params={'ansible_tags': ['check']},
script='some/playbook.yaml',
script_type='ansible'
)
script2_params = [{
'object': {'type': 'cluster'},
'parameters': [{
'key': 'ssl_config',
'value': action['process']['stages']['manage_ssl_stage']['configure_ssl']['config']['ssl_config']
}]
}]
script2 = create_script_template(
display_name='State 2',
name='state_2',
params=script2_params,
script='config_apply',
script_type='internal'
)
return [script1, script2]
### Return
[{'display_name': 'Check',
'name': 'validate',
'params': {'ansible_tags': ['check']},
'script': 'some/playbook.yaml',
'script_type': 'ansible'},
{'display_name': 'State 2',
'name': 'state_2',
'params': [{'object': {'type': 'cluster'},
'parameters': [{'key': 'ssl_config', 'value': 'some_value'}]}],
'script': 'config_apply',
'script_type': 'internal'}]The validate_mapping.j2 file:
- name: validate
display_name: "Precheck"
script_type: ansible
script: some/playbook.yaml
params:
process:
current_stage: {{ action.process.current.stage }}Properties of scripts and scripts_template items
The following properties can be specified for subjobs in scripts and scripts_template:
-
display_name -
name -
on_fail -
params -
script -
script_type
display_name
The display_name property defines the name of the subjob displayed to the user in the ADCM web interface.
name
The name property defines the internal name of the subjob, which must be unique within the action.
on_fail
The on_fail property defines the state to which the object is transitioned if the subjob fails.
params
The params property allows you to pass additional parameters for invoking Ansible. These parameters are used when calling the ansible-playbook command.
One of the supported parameters is ansible_tags. This parameter is a direct equivalent of the --tags argument used when running ansible-playbook.
You can also specify the jinja2_native parameter. This parameter is written to the ansible.cfg file and allows variable types to be preserved during Jinja2 template processing.
script
The script property can take one of the following values, depending on the value of the script_type property:
-
a path to the script file if the
script_typeproperty is set toansible. In the example above, for theinstallaction, thescriptproperty specifies the path to the Ansible playbook located in the <bundle_root>/ansible/site.yaml directory. You can use a dot (.) to specify the script file path. In this case, the script file will be searched for in the directory containing the config.yaml file:script: ./site.yaml
-
one of the built-in ADCM functions if the
script_typeproperty is set tointernal:-
bundle_revert— this function returns the cluster to its state before the upgrade. The cluster state includes its configuration, all services, hosts, and components, as well as the host-component mapping. -
bundle_switch— this function upgrades all prototypes to their new versions. It is designed only for theupgradeaction and cannot be used for other actions. -
hc_apply— this function is useful when an action includeshc_acl, and it becomes necessary to commit the host-component mapping changes regardless of the action execution result or after a certain subjob execution. Thehc_applyfunction commits the host-component mapping changes in accordance with data received from the user. You can use the optionalparamsparameter to commit partial changes. In other words, with theparamsparameter, you can specify a rule similar tohc_acl(the service and component names, and also theaddorremoveoperation) that will commit part of the host-component mapping associated with the specified rule.- name: apply hc script_type: internal script: hc_apply params: rules: - service: redis component: server action: add - service: redis component: server action: remove -
config_apply— this function is useful when an action includeswizard_template, and it becomes necessary to save changes in configuration parameter values, for example, based on data received from the user. You need to specify the rule for committing configuration parameter values and objects using theparamsparameter, which describes an object, a service, and component names corresponding to the object type, and also the set of key/value pairs.NOTETheconfig_applyfunction is available starting with ADCM 2.8.0.- name: save display_name: "Save configuration on target objects" script_type: internal script: config_apply params: changes: - object: type: cluster parameters: - key: "ssl_default_config/keystore_password" value: "my_secret_value" - object: type: service service_name: "hive" parameters: - key: "core-site_xml/keystore_password" value: "my_secret_value" - object: type: component service_name: "hive" component_name: "server" parameters: - key: "core-site_xml/keystore_password" value: "my_value"- name: state_2 display_name: "State 2" script_type: internal script: config_apply params: changes: - object: type: cluster parameters: - key: "{{ ssl_key }}" value: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config }}" - object: type: service service_name: "{{ roles_generic_args.service_name }}" parameters: - key: "{{ ssl_key }}" value: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config }}" - object: type: component service_name: "{{ roles_generic_args.service_name }}" component_name: "{{ roles_generic_args.component_name }}" parameters: - key: "{{ ssl_key }}" value: "{{ action.process.stages.manage_ssl_stage.configure_ssl.config.ssl_config }}" -
service_manage— allows you to add services to a cluster while an action is being executed. It is supported for actions defined at the cluster, service, or component level, including actions implemented as Wizard. It is not supported during the execution of an upgrade operation or for actions defined at the hostprovider, host, or ADCM level. Actions defined at the ADCM level are available on the Settings page.NOTETheservice_managefunction is available starting with ADCM 3.0.0.The list of added services is specified using the
paramsparameter. It contains the following nested parameters:-
operation— operation type. Currently, only theaddvalue is supported. -
services— list of services to add to the cluster. Each service is described by the following attributes:-
name— service name (required). -
parameters— list of service configuration parameters in key/value format (optional). -
mapping— list of host-component mapping rules (optional). Each rule contains:-
component— component name; -
hosts— list of hosts.
-
-
- name: add services script_type: internal script: service_manage params: operation: add services: - name: adqmdb parameters: - key: "Cluster_configuration/replication_factor" value: 2 mapping: - component: adqmdb hosts: ["host-1", "host-2"] - name: prometheus_monitoring -
-
before_upgrade_clean— this function is intended to reduce the size of the inventory file, which allows you to speed up the execution of the Ansible playbooks.IMPORTANTUse thebefore_upgrade_cleanfunction only if you do not need to call thebundle_revertfunction afterward. Thebefore_upgradeparameter context is required to restore the cluster state before the upgrade.The function clears the
before_upgradeparameter for ADCM objects included in the action execution context by resetting it to the default value ({"state": null}). As a result, in the inventory file of the subsequent subjob, thebefore_upgradeparameter does not contain the cluster state formed before the upgrade. Depending on the action level, the function affects the following objects:-
cluster — cluster, its child services, and their components;
-
service — service and its components;
-
component — component;
-
hostprovider — hostprovider and its hosts;
-
host — host.
NOTEIf theallow_for_action_host_group: trueorhost_action: trueproperty is set for the action, then only the object where the action is defined is processed.The
before_upgrade_cleanfunction is available for standard actions, actions implemented as a Wizard, and also during the execution of an upgrade operation. The function can be used for both static (scripts) and dynamic (scripts_template) subjob generation.upgrade: scripts: - name: upgrade_hdfs script_type: ansible script: ansible/site.yaml params: ansible_tags: install jinja2_native: true #...... - name: delete_previous_state_metadata script_type: internal script: before_upgrade_clean -
-
Special actions
The following special actions can be executed in the ADCM web interface and via the specified API endpoints:
-
adcm_turn_on_maintenance_mode -
adcm_turn_off_maintenance_mode -
adcm_host_turn_on_maintenance_mode -
adcm_host_turn_off_maintenance_mode -
adcm_delete_service
An example of a special action definition:
actions:
adcm_turn_on_maintenance_modeSpecial actions should be described in the matching prototypes. The following table lists the special actions available in ADCM, along with their prototype type and description.
| Action name | Type of the prototype | Description |
|---|---|---|
adcm_turn_on_maintenance_mode |
Service/component |
Turns on the maintenance mode on an object via the corresponding element of the ADCM web interface |
adcm_turn_off_maintenance_mode |
Service/component |
Turns off the maintenance mode on an object via the corresponding element of the ADCM web interface |
adcm_host_turn_on_maintenance_mode |
Cluster |
Turns on the maintenance mode on a cluster host via the corresponding element of the ADCM web interface |
adcm_host_turn_off_maintenance_mode |
Cluster |
Turns off the maintenance mode on a cluster host via the corresponding element of the ADCM web interface |
adcm_delete_service |
Service |
Deletes a service via the corresponding element of the ADCM web interface |
Special actions defined in the cluster prototype (adcm_host_turn_on_maintenance_mode and adcm_host_turn_off_maintenance_mode) should also be declared for the host (host_action: true).
|
IMPORTANT
Special actions are not supported for the config, hc_acl, and ui_options properties.
|