Ansible inventory groups
On this page, we will call the group (or inventory group) the set of hosts for the Ansible inventory. Inventory groups are needed so that the bundle developer can use them in playbooks. The amount and types of inventory groups depend on the components defined via bundle DSL.
Inventory file with groups is generated every time when ADCM runs any action, job, or sub job. The generated inventory files are named inventory.json and are located in the mount point of your file system (typically /opt/adcm/run/…). You also can download inventory file using the icon.
The inventory groups that ADCM can form are described below.
Basic groups
These groups include hosts selected on the basis of common characteristics.
Group | Description | Bundle type |
---|---|---|
CLUSTER |
A group that includes all the hosts in the cluster, excluding hosts that are in maintenance mode |
Cluster |
PROVIDER |
A group that includes all hosts of the hostprovider |
Infrastructure |
HOST |
A group that includes a host on which a current action is run |
Infrastructure |
<service name> |
A group that includes all hosts to which the corresponding service has been added, excluding hosts that are in maintenance mode |
Cluster |
<service name>.<component name> |
A group that includes all hosts to which the corresponding component has been added |
Cluster |
Groups for operations with the hc_acl atrribute
These groups are generated by launching an action that has the hc_acl
attribute defined. The groups are named according to the operations.
Group | Description | Bundle type |
---|---|---|
<service name>.<component name>.add |
A group that includes all the hosts that the user has selected to add the corresponding component |
Cluster |
<service name>.<component name>.remove |
A group that includes all the hosts that the user has selected to remove the corresponding component |
Cluster |
Group for operations defined on hosts
This group includes a host where an action with the host_action: true
attribute was launched.
Group | Description | Bundle type |
---|---|---|
target |
A group that includes any host running an operation |
Cluster |
Groups for maintenance mode
These groups include hosts that are in maintenance mode.
Group | Description | Bundle type |
---|---|---|
<service name>.maintenance_mode |
A group that includes all hosts to which the corresponding service has been added, and those hosts are in maintenance mode |
Cluster |
<service name>.<component name>.maintenance_mode |
A group that includes all hosts to which the corresponding component has been added, and those hosts are in maintenance mode |
Cluster |
CLUSTER.maintenance_mode |
A group that includes all cluster hosts that are in maintenance mode |
Cluster |
Groups for special action operations
These groups include a host where the special action was launched (adcm_turn_on_maintenance_mode
, adcm_turn_off_maintenance_mode
).
Group | Description | Bundle type |
---|---|---|
<service name>.maintenance_mode.off |
A group that includes a host to which the corresponding service has been added, and that host is taken out of maintenance mode at a certain point |
Cluster |
<service name>.maintenance_mode.on |
A group that includes a host to which the corresponding service has been added, and that host is put into maintenance mode at a certain point |
Cluster |
<service name>.<component name>.maintenance_mode.off |
A group that includes a host to which the corresponding component has been added, and that host is taken out of maintenance mode at a certain point |
Cluster |
<service name>.<component name>.maintenance_mode.on |
A group that includes a host to which the corresponding component has been added, and that host is put into maintenance mode at a certain point |
Cluster |
Examples
Let us have a cluster that contains 4 hosts. The server
component is located on the test-zookeeper-1
host, the client
component is located on the test-zookeeper-2
host. The server
component is also located on the test-zookeeper-4
host, which has been put into maintenance mode in a separate group.
Let us also have a ZooKeeper service with server
and client
as its components. The service includes all hosts that have components of this service, hence, ZooKeeper includes test-zookeeper-1
and test-zookeeper-2
.
Now we would like to have an action that expands ZooKeeper to the test-zookeeper-3
host. In this case, the inventory.json file will look similar to the one presented below.
{
"all": {
"children": {
"CLUSTER": {
"hosts": {
"test-zookeeper-1": {
...
},
"test-zookeeper-2": {
...
},
"test-zookeeper-3": {
...
}
}
},
"zookeeper.server": {
"hosts": {
"test-zookeeper-1": {
...
}
}
},
"zookeeper": {
"hosts": {
"test-zookeeper-1": {
...
},
"test-zookeeper-2": {
...
}
}
},
"zookeeper.client": {
"hosts": {
"test-zookeeper-2": {
...
}
}
},
"zookeeper.server.add": {
"hosts": {
"test-zookeeper-3": {
...
}
}
},
"zookeeper.server.maintenance_mode": {
"hosts": {
"test-zookeeper-4": {
...
}
}
}
}
}
}
Let us now have an SSH hostprovider bundle and let us also have 2 hosts (ssh-1
and ssh-2
) that were created via that hostprovider.
We run the Create users action on that hostprovider. In this case, the inventory.json file will look similar to the one presented below.
{
"all": {
"children": {
"PROVIDER": {
"hosts": {
"ssh-1": {
...
},
"ssh-2": {
...
}
}
}
}
}
}