Open Stack

Thanks Matt, Craig (cp16net) is working on fixing this.

-amrith

> -----Original Message-----
> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
> Sent: Thursday, November 19, 2015 12:24 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo
> [imm]
> 
> 
> 
> On 11/19/2015 10:22 AM, Amrith Kumar wrote:
> > Just catching up on this thread, have fixes been submitted for this already?
> >
> > Thanks,
> >
> > -amrith
> >
> >> -----Original Message-----
> >> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
> >> Sent: Wednesday, November 18, 2015 2:54 PM
> >> To: openstack-dev at lists.openstack.org
> >> Subject: Re: [openstack-dev] [trove] trove unit tests failing on
> >> stable/kilo
> >>
> >>
> >>
> >> On 11/18/2015 9:23 AM, Matt Riedemann wrote:
> >>>
> >>>
> >>> On 11/17/2015 10:37 PM, Nikhil Manchanda wrote:
> >>>> Thanks for putting up that fix Matt.
> >>>>
> >>>> The dependency on trunk python-troveclient (for stable/kilo)
> >>>> definitely seems
> >>>> screwy-- but I'm wondering if this was done for backwards
> >>>> compatibility reasons?
> >>>> (i.e. to ensure the latest version of python-troveclient should be
> >>>> able to work correctly against all previous releases of trove.)
> >>>
> >>> If that was the plan, https://review.openstack.org/#/c/210004/
> >>> totally blows that up since it's a backward incompatible change and
> >>> was released in a minor version rather than a major version.  That
> >>> change is really what's breaking stable/kilo trove unit tests.
> >>>
> >>>>
> >>>> Either way, I think we should be honoring the requirements
> >>>> specified for the respective releases in g-r, so I think that this
> >>>> is the right fix.
> >>>>
> >>>> Cheers,
> >>>> Nikhil
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Nov 17, 2015 at 7:42 PM, Matt Riedemann
> >>>> <mriedem at linux.vnet.ibm.com
> <mailto:mriedem at linux.vnet.ibm.com>>
> >> wrote:
> >>>>
> >>>>
> >>>>
> >>>>      On 11/17/2015 9:27 PM, Matt Riedemann wrote:
> >>>>
> >>>>
> >>>>
> >>>>          On 11/17/2015 9:22 PM, Matt Riedemann wrote:
> >>>>
> >>>>              I noticed this failing today:
> >>>>
> >>>>
> >>>> http://logs.openstack.org/81/206681/3/check/gate-trove-
> >> python27/45d64
> >>>> 5d/console.html#_2015-11-17_17_07_28_061
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>              Looks like https://review.openstack.org/#/c/218701/ and
> >>>>              maybe the
> >>>>              dependent python-troveclient change would need to be
> >>>>              backported to
> >>>>              stable/kilo (neither are clean backports), or we can just
> >>>>              skip the test
> >>>>              on stable/kilo if there is a good reason why it won't work.
> >>>>
> >>>>
> >>>>          I also see that the unit test job on stable/kilo is
> >>>> pulling in trunk
> >>>>          python-troveclient:
> >>>>
> >>>>
> >>>> http://logs.openstack.org/81/206681/3/check/gate-trove-
> >> python27/45d64
> >>>> 5d/console.html#_2015-11-17_17_07_28_393
> >>>>
> >>>>
> >>>>
> >>>>          Even though we have troveclient capped at 1.1.0 in kilo g-r:
> >>>>
> >>>>
> >>>> https://github.com/openstack/requirements/blob/stable/kilo/global-r
> >>>> eq
> >>>> uirements.txt#L136
> >>>>
> >>>>
> >>>>
> >>>>          So how is that happening?
> >>>>
> >>>>          Oh, because of this:
> >>>>
> >>>>
> >>>> https://github.com/openstack/trove/blob/stable/kilo/test-
> requiremen
> >>>> ts
> >>>> .txt#L17
> >>>>
> >>>>
> >>>>
> >>>>          And that's terrible....why are we doing that?
> >>>>
> >>>>
> >>>>      Attempting to fix here:
> >>>> https://review.openstack.org/#/c/246735/
> >>>>
> >>>>
> >>>>      --
> >>>>
> >>>>      Thanks,
> >>>>
> >>>>      Matt Riedemann
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> __________________________________________________________
> >> ___________
> >>>> _____
> >>>>
> >>>>      OpenStack Development Mailing List (not for usage questions)
> >>>>      Unsubscribe:
> >>>>      OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>>
> >>>> <http://OpenStack-dev-
> >> request at 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-request at lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>
> >>
> >> Getting back to root causes, I discussed with a couple of people in
> >> IRC and wanted to take notes here.
> >>
> >> The root issue was the backward incompatible troveclient change:
> >>
> >> https://review.openstack.org/#/c/210004/
> >>
> >> That was released in 1.3.0 and 1.4.0.  A server side change was made
> >> in liberty that requires that:
> >>
> >> https://review.openstack.org/#/c/218701/
> >>
> >> The troveclient change is breaking stable/kilo since the server side
> >> change isn't in stable/kilo. We could backport that, but given
> >> global-requirements on troveclient in stable/kilo, it's technically invalid:
> >>
> >> https://github.com/openstack/requirements/blob/stable/kilo/global-
> >> requirements.txt#L136
> >>
> >> python-troveclient>=1.0.7,<1.1.0
> >>
> >> Since it's unit tests only and stable/kilo trove is testing against
> >> trunk troveclient, maybe we don't care - we just hack the fix and go
> >> about our merry way.
> >>
> >> I have little stake in trove as a project so it's ultimately up to
> >> the project drivers.
> >>
> >> The right thing to do, IMO, is revert that backward incompatible
> >> troveclient change, release that as 1.4.1, restore the change and then
> release that as 2.0.
> >> We'd also blacklist 1.3.0 and 1.4.0 in global-requirements.
> >>
> >> Unit tests on trove master and stable/liberty would break once the
> >> revert on troveclient landed because the trove unit tests require
> >> that code in troveclient, but that'd be fixed once you revert the
> >> revert (since the trove unit tests run trunk troveclient, not from
> >> released versions). This could be short term pain though and it's
> controllable within the trove core team.
> >>
> >> I think long-term trove should not be unit testing against trunk
> >> troveclient, since it's a false sense of functionality as we've seen
> >> here. Trove should really be requiring the same versions of
> >> troveclient that are specified in global- requirements. Doing that
> >> would make this unit test thing a bit messier though, but not
> unmanageable.
> >>
> >> So, I guess the question is, what does the trove team want to do here?
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Matt Riedemann
> >>
> >>
> >>
> __________________________________________________________
> >> ________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-
> >> request at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> https://review.openstack.org/#/c/246735/ fixes the problem with trunk
> novaclient in the stable/kilo unit tests, but there are other tests failing due to
> what look to be issues with mock.open.  I haven't dug into those.
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev