Open Stack

Jamie,

I’ve updated your review re: u-c oslo.context==2.7.0 in Trove. It will fail but that is understood. I’ve manually tested o.c 2.7.0 and it appears to work.

-amrith

From: Jamie Lennox [mailto:jamielennox at gmail.com]
Sent: Saturday, July 30, 2016 2:17 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [oslo][nova][requirements] Getting oslo.context 2.6.0 into the gate



On 27 July 2016 at 19:10, Tony Breeds <tony at bakeyournoodle.com<mailto:tony at bakeyournoodle.com>> wrote:
On Mon, Jul 18, 2016 at 04:09:54PM +0200, Markus Zoeller wrote:
> Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
> change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
> Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
> Portland and won't be available for the next 2h or so.
> If you can have a look at it and merge it, that would be great.
>
> References:
> [1]
> https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
> [2] https://review.openstack.org/#/c/342604/1
> [3] https://bugs.launchpad.net/nova/+bug/1603979
> [4] logstash: http://goo.gl/79yFb9

I feel like we need to make a plan to more forward and that's going to require
some coordination.

The requirements team saw this coming in that nova's tests failed when 2.6.0
was added to the upper-constraints.txt.  We had a plan[1] but then failed to
execute.  The requirements team has a couple of TODOs from there but the
biggest one is to add actual cross-project gate checks so that we have *very
strong* signals that things will break.

So the state we're in is
oslo.context 2.6.0 is out and used in all projects that *do not* honor upper-constraints.txt
oslo.context 2.5.0 is being used by all projects that *do* honor upper-constraints.txt

The Path forward IMO is

a) Unblock oslo.context 2.6.0
    - But leave upper-constraints.txt pointing to 2.5.0
    - https://review.openstack.org/#/c/347608/
        * We can test shims/fixes against this.

I think this gets easier with the release of 2.7 as we can hopefully just bump minimum requirements to here and forget the whole 2.6 mess.

b) Identify projects that break with > 2.5.0
    - Seems like this is (at least)
        - Trove

check job: https://review.openstack.org/#/c/349204/
[amrith] see comment above; this will not pass. Updated the review. Trove does respect u-c and is currently using 2.5.0; it respects the blacklist of 2.6.0.
        - Nova

check job: https://review.openstack.org/#/c/348204/
        - Designate

check job: https://review.openstack.org/#/c/349205/
        - Others?
c) Add shims to them to work with 2.5.0 and newer
    - Nova: https://review.openstack.org/#/c/342604/ and https://review.openstack.org/#/c/348057/
d) Bump u-c to point at "the latest"
e) Bump the minium in g-r to 2.6.0
f) Remove items from 'c'

Notes:
 - The requirements team will not be able to merge any change that bumps
   oslo.context in u-c until step 'd'.  The reality here is due to our
   tooling/gating that probably means that all u-c changes will be paused
 - As stated in my pre-amble we're working on testing to make this better.
 - We almost certainly need a corss-project session during the design summit to
   discuss the API boundry for the context and how projects are
   expected/allowed to use it.

Thanks Tony. I think this will work well. I hope not many other projects will need the same shims nova did as we've patched a few already.
I completely agree on the cross-project oslo.context session and offer to take that one as there are a number of plans around improving it that have not been properly communicated.

Yours Tony.

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-requirements/%23openstack-requirements.2016-07-15.log.html#t2016-07-15T03:42:24

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160730/9cfa9e4e/attachment.html>