Open Stack

Excerpts from Tony Breeds's message of 2017-09-20 13:43:51 -0400:
> On Wed, Sep 20, 2017 at 01:08:45PM -0400, Doug Hellmann wrote:
> > Excerpts from Jeremy Stanley's message of 2017-09-20 13:36:38 +0000:
> > > On 2017-09-20 08:41:14 -0400 (-0400), Doug Hellmann wrote:
> > > [...]
> > > > Is there any reason not to use the published files for all regular
> > > > builds, instead of having tox.ini point to a git URL? Maybe only for
> > > > regular builds off of stable branches?
> > > 
> > > I'm not sure what you mean by "regular builds" but the plan as I
> > 
> > s/regular/non-CI/
> > 
> > > understood it was to switch from git.o.o URLs to releases.o.o URLs
> > > in the tox.ini files in all branches of projects already consuming
> > > constraints files that way.
> > > 
> > > As early as now (if we already had the publication job in place) we
> > > could update them all in master branches to retrieve something like
> > > https://releases.openstack.org/constraints/queens-upper-constraints.txt
> > > and then once stable/queens is branched in all repos (including the
> > > requirements repo), switch the job to begin publishing to a URL for
> > > rocky and push tox.ini updates to master branches switching the URL
> > > to that as early in the cycle as possible. Alternatively, we could
> > > publish master and queens copies (identical initially) and expect
> > > the master branch tox.ini files to refer to master but then switch
> > > them to queens on the stable/queens branch during RC. It just comes
> > > down to which the stable/requirements/release teams think makes the
> > > most sense from a procedural perspective.
> > 
> > We should think through which of those approaches is going to result in
> > the least amount of synchronization. We do have a window in which to
> > make changes in a given branch for consuming projects, but making the
> > relevant changes in the requirements repository seems like it could be
> > error prone, especially because we try to branch it after the other
> > repositories.
> 
> The solution I thought we decide on at the PTG is:
>  * Add a post job to all branches that publish a constraints/$series.txt
>    to $server (I don't mind if it's releases.o.o or tarballs.o.o).
>  * On the master branch we publish both master.txt and $series.txt
>    (currently queens.txt) when we fork rocky from master we update the
>    publish job to publish master and rocky.txt.    As Doug points out
>    there is a timing race here but it;s much smaller than the one we
>    have now.

Yes, I think that would work. It adds another manual step to the release
process (to update the job) but that can technically be done as soon as
we know the next release name because we can publish from master to as
many different future names as we want.

We're starting to have a fair amount of automation that relies on
knowing the names of the release series and their statuses. I wonder if
we can produce a central library of some sort to give us that
information in a consumable format so we only have to update it in one
place.

>  * We update the projects to use the static (non-git) URL for the
>    constraints files.
>  * We update the release tools to generate the new style URL.
> 
> Optionally, and this requires discussion, we use a custom tox_install.sh
> to extract the branch from .gitreview and generate the URL which would
> remove the need for the last step.  There are clearly pros and cons to
> that so I'm not advocating for it now.
> 
> Those constraints files would never be removed but they'd stop getting
> updated when we EOL the requirements branch.
> 
> How does that sound?

That solves the problem of having the constraints file disappear after
the EOL, but it doesn't really solve the problem of having to update the
branches every time we open one. Having tox_install.sh figure out the
URL from the .gitreview file addresses that, but it may be too magic for
some folks. I don't know if we have generally agreed to let anything
other than git-review look at that file.

Doug