587ccf7c64
As osa cli supports only python3, we should be more specific about it's installation command. Change-Id: Ief18b1bdbe05889baf98ae1e8adadb367fd88bbf
173 lines
5.6 KiB
ReStructuredText
173 lines
5.6 KiB
ReStructuredText
.. _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-<branchname>`` (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, Ubuntu Cloud Archive and openSUSE OBS OpenStack Cloud
|
|
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.
|