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-constrain... 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

On May 27, 2019, at 6:48 PM, Tony Breeds tony@bakeyournoodle.com wrote:

On Mon, May 27, 2019 at 02:48:14PM +0100, Sean Mooney wrote:

...

...

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?

There are a couple of reasons.

1. Using release.o.o allows us is maintain the project state in one

location therefore removing a race around branch time. When pointing directly at git the constraints file for $branch doesn't exist until the requirements repo branches. So if $project merges an update to tox.ini pointing that the constraints file for $branch that project on the new stable branch is running without constraints .... Hmm actually this in more nuanced that I have previously understood as I think we might actually be safe in the gate .... I'll look into that.

The gate always uses a local copy of the constraints list. The race condition is on developers’ local systems, where the old style URL will point to something that does not exist until the requirements repo is branched.

Doug

On May 27, 2019, at 7:28 PM, Tony Breeds tony@bakeyournoodle.com wrote:

...

On Mon, May 27, 2019 at 07:26:11PM -0400, Doug Hellmann wrote:

The gate always uses a local copy of the constraints list. The race condition is on developers’ local systems, where the old style URL will point to something that does not exist until the requirements repo is branched.

I assume that when zuul tries to get the stable/$series branch from openstack/requirements if that branch doesn't exist it just gets master right?

Yours Tony.

Yes, it always works right when running under zuul.

Doug

On Tue, 2019-05-28 at 08:48 +1000, Tony Breeds wrote:

On Mon, May 27, 2019 at 02:48:14PM +0100, Sean Mooney wrote:

...

...

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?

There are a couple of reasons.

1. Using release.o.o allows us is maintain the project state in one

location therefore removing a race around branch time. When pointing directly at git the constraints file for $branch doesn't exist until the requirements repo branches. So if $project merges an update to tox.ini pointing that the constraints file for $branch that project on the new stable branch is running without constraints .... Hmm actually this in more nuanced that I have previously understood as I think we might actually be safe in the gate .... I'll look into that.

2. Using releases.o.o allows the requirements team to EOL branches

without breaking tox files in git / on pypi.

Now clearly neither of these really apply to master, so there it basically comes down to consistency with stable branches where points 1 and 2 make more sense.

ok i wont stand in the way of progress if does infact remove operation hassel for the requiremetns team :)

...

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-constrain... 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.

From where I sit, there are lots of things was *can do* and each has pros and cons. None is right or wrong none is the clear winner. Regardless of which we pick there will be knock-on technical impacts. In Sydney, Dublin we had those discussions, in Vancouver we chose to use the tag/delete process.

I don't want to sound "ranty" and I don't want to close down a conversation but I also don't want to keep talking about it :/

...

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.

Just for clarity s/should also//

we do it for the tox jobs but we dont define it in the env of all jobs like devstack as a result there are edgecases where the local copy is not always used and i have seen intermitent gate failures due to dns or other network issues as a result. specifcally this call in devstack https://github.com/openstack/devstack/blob/master/lib/tempest#L592 so when i ment set it i ment actuly export UPPER_CONSTRAINTS_FILE=/opt/stack/... so that any casual invocation would use the local copy. that said looking at the devstack souce code all direct invocation need a different constraits file then the rest of the job and i dont think any other poject directly invoke tox directly in the gate witout using the tox zuul jobs so setting UPPER_CONSTRAINTS_FILE=/opt/stack/... wont actlly change teh behavior in a constutive way so we can proably ignore this.

Redirects aren't used in the gate.

...

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.

So https://review.opendev.org/#/c/660553/ is ready to merge which does this. It has 3 +2's and just didn't get a +W because Friday. I'd expect this to merge "real soon now". As you point out/imply this will take you from 0 to 1 redirect for tox runs outside of the gate.

So I'm going to propose the change in os-vif along with all the others. Feel free to add a Depends-On or -W until you're happy with it.

its fine i can live with one :) i have had issues in the past with clinet not likeing to follow multiple redirect from behind a proxy but i have not seen that in 2 or 3 years and i nolonger code behind a proxy. one minor thing for people that use squid or other cacheing proxies is that sicne we redirect to https:// they will nolonger get any caching.

we do this if you connect direclty too

sean@pop-os:~/temp$ git clone http://opendev.org/openstack/os-vif Cloning into 'os-vif'... warning: redirecting to https://opendev.org/openstack/os-vif/ remote: Enumerating objects: 2274, done. remote: Counting objects: 100% (2274/2274), done. remote: Compressing objects: 100% (867/867), done. remote: Total 2274 (delta 1395), reused 2169 (delta 1371) Receiving objects: 100% (2274/2274), 430.83 KiB | 1.17 MiB/s, done. Resolving deltas: 100% (1395/1395), done.

i understand why we do this .e.g. secure by default but its one of the downsides of our current redirects.

...

  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?

The bottom line is that as a whole the community decided at some point we run out of time/energy/resources/spoons to maintain those older branches in the gate and at that point a strong signal for that is desirable. The signal we've chosen is the tag/delete process. The EM policy gives many project teams the ability to make those choices for themselves on a schedule that makes sense to them[1]. In this regard requirements is "just a project"[2] that would like to be able to make that call also.

...

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.

So the fixing of lower-constraints is being done by hand not a script/tool and I can confirm os-vif isn't in the list of projects that gets an update ;P

:)

I do have *other* questions about os-vif's tox.ini, they're totally style related so I'll fire off a change as a place to have that discussion at some stage this week.

sure although we deliberately chose to implement things differently in a few places to try and keep our tox config cleaner/simpler. if you have improvement they are welcome although i think stylistically the os-vif tox.ini is cleaner then most :)

Yours Tony.

[1] Without the general schedule outlined in https://docs.openstack.org/project-team-guide/stable-branches.html [2] Okay it's not "just" a project as it has far reaching impacts when it goes EOL but we're trying to reduce/minimise them and the scope for mistakes.