Development¶
Source Code Orientation¶
There are a number of layers to Kayobe, so here we provide a few pointers to the major parts.
CLI¶
The Command Line Interface (CLI) is built using the cliff library. Commands are exposed as Python entry points in setup.cfg. These entry points map to classes in kayobe/cli/commands.py. The helper modules kayobe/ansible.py and kayobe/kolla_ansible.py are used to execute Kayobe playbooks and Kolla Ansible commands respectively.
Ansible¶
Kayobe’s Ansible playbooks live in ansible/*.yml, and these typically execute roles in ansible/roles/. Global variable defaults are defined in group variable files in ansible/inventory/group_vars/all/ and these typically map to commented out variables in the configuration files in etc/kayobe/*.yml. A number of custom Jinja filters exist in ansible/filter_plugins/*.py. Kayobe depends on roles and collections hosted on Ansible Galaxy, and these and their version requirements are defined in requirements.yml.
Ansible Galaxy¶
Kayobe uses a number of Ansible roles and collections hosted on Ansible Galaxy.
The role dependencies are tracked in requirements.yml, and specify required
versions. The process for changing a Galaxy role or collection is as follows:
If required, develop changes for the role or collection. This may be done outside of Kayobe, or by modifying the code in place during development. If upstream changes to the code have already been made, this step can be skipped.
Commit changes to the role or collection, typically via a Github pull request.
Request that a tagged release of the role or collection be made, or make one if you have the necessary privileges.
Ensure that automatic imports are configured for the repository using e.g. a webhook notification, or perform a manual import of the role on Ansible Galaxy.
Modify the version in
requirements.ymlto match the new release of the role or collection.
