[Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging

Doug Hellmann doug at doughellmann.com
Tue Jun 5 14:36:57 UTC 2018

Excerpts from Jean-Philippe Evrard's message of 2018-06-05 10:14:12 +0200:
> Hello,
> *TL:DR;* If you are an openstack-ansible user, consuming our roles directly,
> with tags, without using openstack-ansible plays or integrated repo,
> then things will change for you. Start using git shas instead of tags.
> All other openstack-ansible users should not see a difference, even if
> they use openstack-ansible tags.
> During the summit, I had a discussion with dhellman (and smcginnis)
> to change how openstack-ansible does its releases.
> Currently, we tag openstack-ansible + many roles under our umbrella
> every two weeks. As far as I know, nobody requested to have roles
> tagged every two weeks. Only OpenStack-Ansible need to be tagged
> for consumption. Even people using our roles directly outside
> openstack-ansible generally use sha for roles. We don't rely on
> ansible galaxy.
> Because there is no need to tag the roles, there is no need to make them
> part of the "openstack-ansible" deliverable [1][2]. I will therefore
> clarify the governance repo for that, separating the roles, each of them
> with their own deliverable, instead of grouping some roles within
> openstack-ansible, and some others outside it.
> With this done, a release of openstack-ansible becomes straightforward
> using the standard release tooling. The releases of openstack-ansible
> becomes far simpler to request, review, and will not have timeouts
> anymore :p
> There are a few issues I see from the change. Still according to the
> discussion, it seems we can overcome those.
> 1. As this will be applied on all the branches, we may reach some
> issues with releasing in the next days. While the validate tooling
> of releases has shown me that it wouldn't be a problem (just
> warning) to not have all the repos in the deliverable, I would
> expect a governance change could be impactful.
> However, that is only impacting openstack-ansible, releases,
> and governance team: Keep in mind, openstack-ansible will not
> change for its users, and will still be tagged as you know it.
> 2. We will keep branching our roles the same way we do now. What
> we liked for roles being part of this deliverable, is the ability
> of having them automatically branched and their files adapted.
> To what I heard, it is still possible to do so, by having a
> devstack-like behavior, which branches on a sha, instead of
> branching on tag. So I guess it means all our roles will now be
> part of release files like this one [3], or even on a single release
> file, similar to it.

Right, you can set the stable-branch-type field to 'tagless' (see
http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n462) and
then set the branch location field to the SHA you want to use.

If you would be ready to branch all of the roles at one time, you could
put all of them into 1 deliverable file. Otherwise, you will want to
split them up into their own files.

And since you have so many, I will point out that we're really into
automation over here on the release team, and if you wanted to work on
making the edit-deliverable command smart enough to determine the SHA
for you I could walk you through that code to get you started.


> What I would like to have, from this email, is:
> 1. Raise awareness to all the involved parties;
> 2. Confirmation we can go ahead, from a governance standpoint;
> 3. Confirmation we can still benefit from this automatic branch
> tooling.
> Thank you in advance.
> Jean-Philippe Evrard (evrardjp)
> [1]: https://github.com/openstack/governance/blob/8215c5fd9b464b332b310bbb767812fefc5d9174/reference/projects.yaml#L2493-L2540
> [2]: https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/openstack-ansible.yaml#L768-L851
> [3]: https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/devstack.yaml

More information about the OpenStack-operators mailing list