Re: [openstack-dev] [keystone][oslo][release][requirements][FFE] global-requirements update to positional to 1.1.1

[Tony Breeds]

On Tue, Sep 13, 2016 at 09:03:52AM +0800, Jamie Lennox wrote:

> So the major difference between positional 1.0 and 1.1 is that we swapped
> from using a @functools.wrap decorator to a @wrapt decorator. The reason
> for this is that @functools.wraps basically screws up any inspection of the
> function signature.

Yeah I heard abotu wrapt at PyCon-AU[1] this year.  Good stuff

> Barbican failing this difference means it's inspecting
> oslo.context.RequestContext [1] and it looks like it's doing this so it can
> tell the difference between before and after oslo.context 2.2. Given we're
> at 2.9 in minimum requirements we can just remove this and all should be ok.
> 
> Patch: https://review.openstack.org/#/c/369092/

Thanks so much Jamie!   That's a much better solution than bumping g-r and
re-releasing the keystone libraries

Yours Tony.

[1] https://youtu.be/u7oj-ghfhUk


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][oslo][release][requirements][FFE] global-requirements update to positional to 1.1.1

[Jamie Lennox]

On 8 September 2016 at 11:29, Tony Breeds  wrote:

> On Wed, Sep 07, 2016 at 08:10:45AM -0500, Matthew Thode wrote:
> > https://review.openstack.org/366631
> >
> > The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the
> > current minimum requirement) results in various unit test failures in
> > barbican, related to parsing of request headers in generated contexts
> > for unit testing.  Updating to 1.1.1 resolves this issue.
>
> I'd really like to get to the bottom of exactly what these failures are
> and how
> they can be fixed.  I'd ask why we didn't catch them sooner but that boils
> down
> to us not actually testing our lower-bounds.
>
> https://bugs.launchpad.net/oslo.context/+bug/1620963 indicates that
> they're
> unit test failures but elsewhere I saw functional tests mentioned.  Have we
> uncovered a real issue or a testing defect?
>
> > This is specifically affecting barbican and RDO testing (from discussion
> > and the review).
> >
> > The reason I think an FFE is needed is because downstream packagers,
> > while encouraged to package based on upper-constraints sometimes don't.
> > Meaning they'd miss something like this.
>
> Yeah it's complex.  We've stated several  times that this is the contract
> we
> make with downstream that we test with u-c and that's our reccomendation
> for
> packaging.  While I agree that we shoudl test our minimums that's not a
> thing
> we can do right now[1]
>
> I agree that it's wrong to state our minimum is 1.0.1 when we *know* that
> it's
> 1.1.1, I'm not convinced the know that yet.
>
> > Arguments against are that this will have knock on effects down the line
> > (will require re-releases and re-re-releases because of updating things
> > like keystone (this is deep in the depgraph)), so is bad from a release
> > team work point of view.  Also, I think this just effects testing, so
> > the impact of this is more minor than something more serious (not JUST
> > breaking testing).
>
> Here's my summary of the changes needed to bump the minimum[2]
>
> Package  : positional [positional>=1.0.1] (used by 4 projects)
> Re-Release   : 4 projects
> openstack/keystoneauth[type:library]
> openstack/keystonemiddleware  [type:library]
> openstack/oslo.context[type:library]
> openstack/python-keystoneclient   [type:library]
>
> Each of those 4 libraries have stable/newton branches that only contain
> updates to .gitreview
> origin/master : keystoneauth1===2.12.1
> origin/master : keystonemiddleware===4.9.0
> origin/master : oslo.context===2.9.0
> origin/master : python-keystoneclient===3.5.0
>
> So if we take the g-r change we'd need to release
>
> keystoneauth1===2.13.0
> keystonemiddleware===4.10.0
> oslo.context===2.10.0
> python-keystoneclient===3.6.0
>
> All of which would be accepted by global-requirements
>
> I know during the requirements meeting I sdaid I was worried about
> secondary
> release effects but if I follow correctly they'll be minimal.
>
> I guess that's a long way of saying we need someone that knows about
> oslo.context and hopefully barbican to look at this
>
> Yours Tony.
>
> [1] I just had an idea for a crazy hack that might kinda work to generate
> lower-constraints.txt something to look at Ocata :)
> [2] If we don't do this befoer we branch stable/newton then we *can't* do
> it.
>

So the major difference between positional 1.0 and 1.1 is that we swapped
from using a @functools.wrap decorator to a @wrapt decorator. The reason
for this is that @functools.wraps basically screws up any inspection of the
function signature.

Barbican failing this difference means it's inspecting
oslo.context.RequestContext [1] and it looks like it's doing this so it can
tell the difference between before and after oslo.context 2.2. Given we're
at 2.9 in minimum requirements we can just remove this and all should be ok.

Patch: https://review.openstack.org/#/c/369092/


[1]
http://git.openstack.org/cgit/openstack/barbican/tree/barbican/context.py?h=3.0.0.0b3#n43


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

Re: [openstack-dev] [keystone][oslo][release][requirements][FFE] global-requirements update to positional to 1.1.1

[Tony Breeds]

On Wed, Sep 07, 2016 at 08:10:45AM -0500, Matthew Thode wrote:
> https://review.openstack.org/366631
> 
> The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the
> current minimum requirement) results in various unit test failures in
> barbican, related to parsing of request headers in generated contexts
> for unit testing.  Updating to 1.1.1 resolves this issue.

I'd really like to get to the bottom of exactly what these failures are and how
they can be fixed.  I'd ask why we didn't catch them sooner but that boils down
to us not actually testing our lower-bounds.

https://bugs.launchpad.net/oslo.context/+bug/1620963 indicates that they're
unit test failures but elsewhere I saw functional tests mentioned.  Have we
uncovered a real issue or a testing defect?

> This is specifically affecting barbican and RDO testing (from discussion
> and the review).
> 
> The reason I think an FFE is needed is because downstream packagers,
> while encouraged to package based on upper-constraints sometimes don't.
> Meaning they'd miss something like this.

Yeah it's complex.  We've stated several  times that this is the contract we
make with downstream that we test with u-c and that's our reccomendation for
packaging.  While I agree that we shoudl test our minimums that's not a thing
we can do right now[1]

I agree that it's wrong to state our minimum is 1.0.1 when we *know* that it's
1.1.1, I'm not convinced the know that yet.

> Arguments against are that this will have knock on effects down the line
> (will require re-releases and re-re-releases because of updating things
> like keystone (this is deep in the depgraph)), so is bad from a release
> team work point of view.  Also, I think this just effects testing, so
> the impact of this is more minor than something more serious (not JUST
> breaking testing).

Here's my summary of the changes needed to bump the minimum[2]

Package  : positional [positional>=1.0.1] (used by 4 projects)
Re-Release   : 4 projects
openstack/keystoneauth[type:library]
openstack/keystonemiddleware  [type:library]
openstack/oslo.context[type:library]
openstack/python-keystoneclient   [type:library]

Each of those 4 libraries have stable/newton branches that only contain updates 
to .gitreview
origin/master : keystoneauth1===2.12.1
origin/master : keystonemiddleware===4.9.0
origin/master : oslo.context===2.9.0
origin/master : python-keystoneclient===3.5.0

So if we take the g-r change we'd need to release

keystoneauth1===2.13.0
keystonemiddleware===4.10.0
oslo.context===2.10.0
python-keystoneclient===3.6.0

All of which would be accepted by global-requirements

I know during the requirements meeting I sdaid I was worried about secondary
release effects but if I follow correctly they'll be minimal.

I guess that's a long way of saying we need someone that knows about
oslo.context and hopefully barbican to look at this

Yours Tony.

[1] I just had an idea for a crazy hack that might kinda work to generate
lower-constraints.txt something to look at Ocata :)
[2] If we don't do this befoer we branch stable/newton then we *can't* do it.


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev