About the constraints url.

Sean Mooney smooney at redhat.com
Mon May 27 13:48:14 UTC 2019


On Mon, 2019-05-27 at 08:33 +0100, Stephen Finucane wrote:
> On Mon, 2019-05-27 at 09:18 +0200, Natal Ngétal wrote:
> > Hi everyone,
> > 
> > I'm little lost or totally lost, actually. Sorry if a mail have
> > already sent, I have not find it. If I have understood correctly, the
> > url to use for the constraints is:
> > 
> > https://releases.openstack.org/constraints/upper/master
> > 
> > One question, this rule is the same for all projects? I'm also bit
> > confused, I know the oslo projects must be use this url, and I have a
> > patch is blocked for this reason:
> > 
> > https://review.opendev.org/#/c/658296/
> > 
> > The url is not good in master also, so I have make a patch for it:
> > 
> > https://review.opendev.org/#/c/661100/
> > 
> > So why I'm confused, because in the same project, few patches with the
> > bad url was validate or merge:
> > 
> > https://review.opendev.org/#/c/655650/
> > https://review.opendev.org/#/c/655649/
> > https://review.opendev.org/#/c/655648/
> > https://review.opendev.org/#/c/655640/
> > 
> > So which url must be used for constraints and this a global for all
> > openstack projects? Then can we be careful, when we review a patch
> > about this and not mixed up both url.
> 
> The wording there is admittedly confusing: these URLs aren't "wrong",
> per se, they're just not what we're aiming for going forward.
> You
> probably want to look at this email:
> 
> http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006478.html
> 
> The reason for the -1s is presumably so we can do things correctly now
> rather than having to fix them again in the future.
why would we prefer the release repo over git?
i would much prefer if we coninued to use the direct opendev based git urls
instead of relying on the redirect as we do here
https://github.com/openstack/os-vif/blob/master/tox.ini#L12

https://releases.openstack.org/constraints/upper/master is just a redirect to 
https://opendev.org/openstack/requirements/raw/branch/master/upper-constraints.txt
which is rather inefficient. would a better soluton to the EOL branches not be
dont delete the branch in the first place and just merge a commit declaring it eol.

with extended maintenance i think that makes even more sense now then it did before.

as a side note in the gate jobs we should also set the UPPER_CONSTRAINTS_FILE env to point a the
copy created by the zuul cloner rather then relying on either approch.

im not going to -1 patches that update to the 
https://releases.openstack.org/constraints/upper/$series form although i would prefer
people do not do it on os-vif until the http{s,}://releases.openstack.org/constraints/upper/master
redirect actully use opendev.org as we have already made that switch and i dont want to go form 0 redirects
to 2. i would like to know why we continue to kill the stable branches for when the go EOL as that is the
root of one of the issues raised. Tony do you have insight into that?
os-vif's lower constratis job is also not broken in they way that was described in the email so if an automated patch is
recived that would regress that ill -2 it and then fix it up.



> 
> Hope that makes sense,
> Stephen
> 
> 




More information about the openstack-discuss mailing list