.. _periodicwork: ============= Periodic Work ============= Releasing ========= Our release frequency is discussed in :ref:`reference_release`. OSA CLI tooling --------------- OpenStack-Ansible used to bump everything in a single script, which made it hard to maintain, and was very branch specific. It made it hard for users to consume either an update of the upstream shas, or to bump roles with their own pace. Since then, the OpenStack-Ansible has agreed to provide more metadata necessary for releasing into the openstack-ansible code tree. This allowed the tooling for releasing to be more flexible, and lighter, over time. Now, all the functions are separated, and included into a branch independent tooling, `osa_cli_releases`. .. _osa_cli_releases: https://github.com/evrardjp/osa_cli_releases You can install the latest version of this tooling by running: .. parsed-literal:: pip3 install -e git+https://github.com/evrardjp/osa-cli.git#egg=openstack_ansible_cli pip3 install -e git+https://github.com/evrardjp/osa_cli_releases.git#egg=osa_cli_releases This tooling can then be called using ``osa releases``. Each subcommand contains help by default. Updating upstream SHAs ---------------------- The dependencies for OpenStack-Ansible are updated through the use of ``osa releases bump_upstream_shas``. This script updates the project's pinned SHAs, located in the `repo_packages folder`, based on their ``_git_track_branch`` value. .. _repo_packages folder: https://github.com/openstack/openstack-ansible/tree/master/playbooks/defaults/repo_packages Updating OpenStack-Ansible roles -------------------------------- Updating the roles to their latest version per branch is done through ``osa releases bump_roles $gitbranchname``. This can do multiple things: * Freeze ansible-role-requirements to their latest SHAs for the branch they are tracking. * Copy release notes relevant to the freeze. * Unfreeze of master. Master doesn't get frozen, unless explicitly asked for it for release milestones, using the command ``osa releases freeze_roles_for_milestone`` Check current pins status ------------------------- You can check the current PyPI pins that are used in openstack-ansible repository by running ``osa releases check_pins``. This will display a table, showing the current pin in OSA, and what is available upstream on PyPI. This doesn't patch the ``global-requirements-pins``, as this should be a manual operation. See the :ref:`cycle-checklist` to know when to bump the global-requirements-pins. Adding patch in releases repo ----------------------------- When the patches to update SHAs and roles have landed, you can propose the parent SHA as a release in the releases repo. This can be done using the ``new-release`` command, and then editing the SHA used for openstack-ansible. See also `new_releases page`_ for an explanation of this command. Please note that branches before Stein will require cleanup of the YAML file generated by new_releases, as it will contain ALL the roles and openstack-ansible repo SHAs. We have decided to NOT tag the roles anymore, so you will need to remove all the lines which are not relevant to the `openstack-ansible` repository. .. _new_releases page: https://releases.openstack.org/reference/using.html#using-new-release-command .. _cycle-checklist: Development cycle checklist =========================== On top of the normal cycle goals, a contributor can help the OpenStack-Ansible development team by performing one of the following recurring tasks: * By milestone 1: * Community goal acknowledgement. * Update ``global-requirements-pins`` * By milestone 2: * Handle deprecations from upstream project's previous cycle. * Handle OpenStack-Ansible roles deprecations from the previous cycle. * Refresh static elements in roles. For example, update a specific version of the software packages. * Bump ``ceph_stable_release`` to latest Ceph LTS release in the integrated OpenStack-Ansible repo, and inside the ``ceph_client`` role defaults. * Check and bump galera versions if required. * Check and bump rabbitmq versions if required. * Check outstanding reviews and move to merge or abandon them if no longer valid. * Update ``global-requirements-pins`` * By milestone 3: * Implement features * Update ``global-requirements-pins`` * After milestone 3: * Feature freeze, bug fixes, and testing improvements. * After creating a new stable branch: * For all the repos, update the eventual static files refering to master/previous branch name. The main documentation should be updated to add the new branch. The #openstack-docs team should also be updated, for linking the newly created deployment-guide. Use the topic ``create-`` (e.g: ``create-stein``) for future reference. * Branch all the independent repos that aren't part of the release in gerrit. See also the ``projects.yaml`` in the governance repo. Manually branched repos need extra editions, like updating the .gitreview, or the reno index. Please reference previous branch creations by using the appropriate topic in gerrit (e.g.: ``create-stein``). The previous new branch creation may be different as the tooling/process may have evolved, so be aware that the changes needed may need to be adapted. * After official project release, before official OpenStack-Ansible release: * Bump RDO and Ubuntu Cloud Archive repositories if they are ready on time. * Immediately after official OpenStack-Ansible release: * Send a thank you note to all the contributors through the mailing lists. They deserve it.