[openstack-dev] [keystone] [Openstack-stable-maint] Build failed in Jenkins: periodic-keystone-python27-stable-folsom #84

Dolph Mathews dolph.mathews at gmail.com
Fri Jan 4 20:32:18 UTC 2013


-Dolph


On Fri, Jan 4, 2013 at 4:53 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Fri, 2013-01-04 at 11:12 +0100, Thierry Carrez wrote:
> > Mark McLoughlin wrote:
> > >> To fix the stable/folsom issues, how about we say that the
> stable/folsom
> > >> tests only need to test the 0.2.0 version of keystoneclient, not
> master?
> > >>
> > >> That's as simple as this change:
> > >>
> > >>   @@ -789,7 +789,7 @@ class KeystoneClientTests(object):
> > >>
> > >>    class KcMasterTestCase(CompatTestCase, KeystoneClientTests):
> > >>        def get_checkout(self):
> > >>   -        return KEYSTONECLIENT_REPO, 'master'
> > >>   +        return KEYSTONECLIENT_REPO, '0.2.0'
> > >>
> > >>        def test_tenant_add_and_remove_user(self):
> > >>            client = self.get_client(admin=True)
> > >
> > > Proposed here: https://review.openstack.org/18898
> >
> > Mixed feelings: we are supposed to always use the latest client --
> > that's why there is no stable/folsom branch of the client.
>
> Right, but there's something very wrong with using keystone
> stable/folsom unit tests to catch regressions in keystoneclient master.
>
>
+1; changes to keystoneclient should be gated by compatibility with
targeted releases of keystone (which happens to be all of them at this
point), rather than the other way around (e.g. gating keystone stable
branches on future keystoneclient changes).


> Testing keystone stable/folsom with keystoneclient 0.2.0 is fine because
> it will catch regressions in keystone itself.
>
> For catching regressions in keystoneclient master, the keystoneclient
> testing which happens on keystone master is sufficient.
>
> > The real issue here is the test itself. I'm fine with this as a
> > temporary workaround to unblock keystone stable/folsom, as long as it's
> > clear that this test needs to be rewritten (or moved to tempest).
>
> Yes, it's a stopgap measure.
>
> Cheers,
> Mark.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130104/10c4ed2f/attachment.html>


More information about the OpenStack-dev mailing list