<div dir="ltr"><br><div class="gmail_extra"><br clear="all"><div><div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Fri, Jan 4, 2013 at 4:53 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, 2013-01-04 at 11:12 +0100, Thierry Carrez wrote:<br>
> Mark McLoughlin wrote:<br>
> >> To fix the stable/folsom issues, how about we say that the stable/folsom<br>
> >> tests only need to test the 0.2.0 version of keystoneclient, not master?<br>
> >><br>
> >> That's as simple as this change:<br>
> >><br>
> >>   @@ -789,7 +789,7 @@ class KeystoneClientTests(object):<br>
> >><br>
> >>    class KcMasterTestCase(CompatTestCase, KeystoneClientTests):<br>
> >>        def get_checkout(self):<br>
> >>   -        return KEYSTONECLIENT_REPO, 'master'<br>
> >>   +        return KEYSTONECLIENT_REPO, '0.2.0'<br>
> >><br>
> >>        def test_tenant_add_and_remove_user(self):<br>
> >>            client = self.get_client(admin=True)<br>
> ><br>
> > Proposed here: <a href="https://review.openstack.org/18898" target="_blank">https://review.openstack.org/18898</a><br>
><br>
> Mixed feelings: we are supposed to always use the latest client --<br>
> that's why there is no stable/folsom branch of the client.<br>
<br>
</div>Right, but there's something very wrong with using keystone<br>
stable/folsom unit tests to catch regressions in keystoneclient master.<br>
<br></blockquote><div><br></div><div style>+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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Testing keystone stable/folsom with keystoneclient 0.2.0 is fine because<br>
it will catch regressions in keystone itself.<br>
<br>
For catching regressions in keystoneclient master, the keystoneclient<br>
testing which happens on keystone master is sufficient.<br>
<div class="im"><br>
> The real issue here is the test itself. I'm fine with this as a<br>
> temporary workaround to unblock keystone stable/folsom, as long as it's<br>
> clear that this test needs to be rewritten (or moved to tempest).<br>
<br>
</div>Yes, it's a stopgap measure.<br>
<br>
Cheers,<br>
Mark.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>