Integration with the bundle

When the bundle is loaded into ADCM, the backend receives a request that triggers the following process.

All bundle files are unpacked and put into the file system (<adcm container mount point>/bundle/<bundle hash>). Each bundle is unpacked to its corresponding directory and has a unique hash. This allows playbooks and roles of different products not to be mixed up — each playbook is stored inside its corresponding bundle.

After unpacking the bundle, ADCM parses a special file called config.yaml or config.yml. This file can be located in any directory of the bundle. There may be multiple config.yaml files — in which case ADCM finds all files with that name the bundle contains.

After searching for the config.yaml files, each of these files undergoes processing. This processing involves creating prototype entities in ADCM based on their descriptions in the config.yaml files. This is how metainformation about ADCM objects is created. The backend interacts with the database: all the described prototypes, their actions, configurations, and other related information are written into the database.

When starting an action on an ADCM object, metainformation about that action is requested from the database (for example, whether it contains the config or config_jinja configuration that should be requested from the user before running the action, or whether the components need to be placed on the hc_acl host). The backend returns this metainformation, and the UI uses it to generate appropriate forms to interact with the user.

The metainformation from the backend is also used to generate a task that is sent to the task runner for processing, which generates a chain of jobs, each of which is then run by the job runner. In essence, the job runner starts the Ansible playbooks that are specified in the script section of the action or subaction. When running, these Ansible playbooks can call Ansible modules and plugins added during the bundle development.