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/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 hosted on Ansible Galaxy, and these and their version requirements are defined in requirements.yml.
Ansible Galaxy¶
Kayobe uses a number of Ansible roles hosted on Ansible Galaxy. The role
dependencies are tracked in requirements.yml, and specify required
versions. The process for changing a Galaxy role is as follows:
If required, develop changes for the role. This may be done outside of Kayobe, or by modifying the role in place during development. If upstream changes to the role have already been made, this step can be skipped.
Commit changes to the role, typically via a Github pull request.
Request that a tagged release of the role be made, or make one if you have the necessary privileges.
Ensure that automatic imports are configured for the role using e.g. a TravisCI 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.
