Open Stack

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