[openstack-dev] [requirements][stable] publish upper-constraints.txt periodic vs post

Doug Hellmann doug at doughellmann.com
Thu Sep 21 16:09:52 UTC 2017

Excerpts from Matthew Thode's message of 2017-09-21 10:43:50 -0500:
> On 17-09-20 14:09:15, Tony Breeds wrote:
> > On Wed, Sep 20, 2017 at 01:43:51PM -0400, Tony Breeds wrote:
> > 
> > > 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).
> > 
> > Actually we might be better to do this daily from the periodic pipeline.
> > In our CI we always gate with what is in git so that wouldn't be
> > impacted.  The question is do we need external consumers to be "up to
> > the minute" or is a days lag acceptable?
> > 
> > I kinda feel like it's okay to be a little laggy.
> > 
> > Yours Tony.
> I don't think this should be periodic, I'll try to argue the point via a
> pros/cons listing.  I think we should be trying to have users use
> upper-constraints via what is currently known as stable, to me that
> means more often than once a day.
> I'm probably a bit biased, so feel free to update :D
> pros - periodic
> * simple update schedule (once a day)
> * easier on infra (publish just once vs up to 20-30 times a day)
> cons - periodic
> * point in time (once a day) does not guarantee that that point works
>   while we try to ensure all projects are not impacted by changes, we
>   are not perfect
> * we would be making it harder for people to use upper-constraints externally
>   for one thing (via longer turn around time)
> * some projects may be using upper-constraints.txt from the url only
> pros - post
> * upper-constraints are available via published location immediately
> * sets good precident for end users/devs to use it
> cons - post
> * both breaks and fixes quick
> * more load on infra to publish (20-30 times a day)

Another point against a periodic job is that it would be a change from
what we're doing now, where constraints are updated as soon as the git
cache is updated.

I think we should publish using a post-merge job. The job isn't
expensive, right? It's just copying some files out of git onto the
web server?

Do we really land 20-30 changes to the constraints list on an average


More information about the OpenStack-dev mailing list