<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 8 September 2016 at 11:29, Tony Breeds <span dir="ltr"><<a href="mailto:tony@bakeyournoodle.com" target="_blank">tony@bakeyournoodle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wed, Sep 07, 2016 at 08:10:45AM -0500, Matthew Thode wrote:<br>
> <a href="https://review.openstack.org/366631" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>366631</a><br>
><br>
> The combination of oslo.context 2.9.0 + positional 1.0.1 (which is the<br>
> current minimum requirement) results in various unit test failures in<br>
> barbican, related to parsing of request headers in generated contexts<br>
> for unit testing. Updating to 1.1.1 resolves this issue.<br>
<br>
</span>I'd really like to get to the bottom of exactly what these failures are and how<br>
they can be fixed. I'd ask why we didn't catch them sooner but that boils down<br>
to us not actually testing our lower-bounds.<br>
<br>
<a href="https://bugs.launchpad.net/oslo.context/+bug/1620963" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>oslo.context/+bug/1620963</a> indicates that they're<br>
unit test failures but elsewhere I saw functional tests mentioned. Have we<br>
uncovered a real issue or a testing defect?<br>
<span class="gmail-"><br>
> This is specifically affecting barbican and RDO testing (from discussion<br>
> and the review).<br>
><br>
> The reason I think an FFE is needed is because downstream packagers,<br>
> while encouraged to package based on upper-constraints sometimes don't.<br>
> Meaning they'd miss something like this.<br>
<br>
</span>Yeah it's complex. We've stated several times that this is the contract we<br>
make with downstream that we test with u-c and that's our reccomendation for<br>
packaging. While I agree that we shoudl test our minimums that's not a thing<br>
we can do right now[1]<br>
<br>
I agree that it's wrong to state our minimum is 1.0.1 when we *know* that it's<br>
1.1.1, I'm not convinced the know that yet.<br>
<span class="gmail-"><br>
> Arguments against are that this will have knock on effects down the line<br>
> (will require re-releases and re-re-releases because of updating things<br>
> like keystone (this is deep in the depgraph)), so is bad from a release<br>
> team work point of view. Also, I think this just effects testing, so<br>
> the impact of this is more minor than something more serious (not JUST<br>
> breaking testing).<br>
<br>
</span>Here's my summary of the changes needed to bump the minimum[2]<br>
<br>
Package : positional [positional>=1.0.1] (used by 4 projects)<br>
Re-Release : 4 projects<br>
openstack/keystoneauth [type:library]<br>
openstack/keystonemiddleware [type:library]<br>
openstack/oslo.context [type:library]<br>
openstack/python-<wbr>keystoneclient [type:library]<br>
<br>
Each of those 4 libraries have stable/newton branches that only contain updates to .gitreview<br>
origin/master : keystoneauth1===2.12.1<br>
origin/master : keystonemiddleware===4.9.0<br>
origin/master : oslo.context===2.9.0<br>
origin/master : python-keystoneclient===3.5.0<br>
<br>
So if we take the g-r change we'd need to release<br>
<br>
keystoneauth1===2.13.0<br>
keystonemiddleware===4.10.0<br>
oslo.context===2.10.0<br>
python-keystoneclient===3.6.0<br>
<br>
All of which would be accepted by global-requirements<br>
<br>
I know during the requirements meeting I sdaid I was worried about secondary<br>
release effects but if I follow correctly they'll be minimal.<br>
<br>
I guess that's a long way of saying we need someone that knows about<br>
oslo.context and hopefully barbican to look at this<br>
<br>
Yours Tony.<br>
<br>
[1] I just had an idea for a crazy hack that might kinda work to generate<br>
lower-constraints.txt something to look at Ocata :)<br>
[2] If we don't do this befoer we branch stable/newton then we *can't* do it.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>Patch: <a href="https://review.openstack.org/#/c/369092/">https://review.openstack.org/#/c/369092/</a><br></div><div><br><br>[1] <a href="http://git.openstack.org/cgit/openstack/barbican/tree/barbican/context.py?h=3.0.0.0b3#n43">http://git.openstack.org/cgit/openstack/barbican/tree/barbican/context.py?h=3.0.0.0b3#n43</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>