Open Stack

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.

In any case, I like whichever approach can be made to work and will
leave bikeshedding on URLs paths to the reviews that implement the
one we pick.

If it would be useful, I would be happy to help advise anyone who
wants to modify the release automation scripts to handle this new
case.

Doug

> Remember also that the timing on this doesn't require extreme
> precision and there are no chicken-and-egg/catch-22 problems
> associated with updating because the URLs in question are merely a
> fallback method for when the constraints file is not already
> provided locally. In the CI system, we directly provide constraints
> files so that we can respect depends-on to requirements repo changes
> and the like, so in practice this fallback is primarily for the
> convenience of developers running tox locally.