Open Stack

On 17-09-20 13:43:51, Tony Breeds wrote:
> 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.
>  * 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?
> 
> Yours Tony.

That's correct, I haven't had time this week to create the jobs quite
yet, but hope to do so either this weekend or next week.

It's #3 in our list of items to generate tasks/bugs from.
https://etherpad.openstack.org/p/queens-PTG-requirements

-- 
Matthew Thode (prometheanfire)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170920/e693886c/attachment.sig>