<div dir="ltr"><div><br></div>Responses inline.<br><div><br><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 9, 2013 at 10:07 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</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"><div class="im">On 12/09/2013 10:12 AM, Brant Knudson wrote:<br>
> Monty -<br>
><br>
> Thanks for doing the work already to get the infrastructure set up.<br>
> Looks like I've got the easy part here. I posted an initial patch that<br>
> has one test from keystone in <a href="https://review.openstack.org/#/c/60724/" target="_blank">https://review.openstack.org/#/c/60724/</a> .<br>
> I hope to be able to move all the tests over unchanged. The tricky part<br>
> is getting all the fixtures set up the same way that keystone does.<br>
<br>
</div>I think a direct port of the keystone fixtures is the wrong approach.<br>
These really need to act more like the scenario tests that exist over<br>
there. And if the intent is just a dump of the keystone tests we need to<br>
step back... because that's not going to get accepted.<br>
<br></blockquote><div><br></div><div>The reason I'd like to keep keystone's client tests as they are is that they provide us with coverage of keystone and keystoneclient functionality. This doesn't mean they have to stay that way forever, since once they're moved out of Keystone we can start refactoring them.<br>
</div><div><br></div><div>An alternative approach is to clean up Keystone's client tests as much as possible first to make them essentially the scenario tests that tempest would accept. This would leave the tests in keystone longer than we'd like since we'd like them out of there ASAP.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I actually think that we should solve #4 first - how you test the thing<br>
you actually want to test in the gate. Which is about getting<br>
devstack-gate to setup the world that you want to test. I really think<br>
the location of the tests all flow from there. Because right now it<br>
seems like the cart is before the horse.<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>OK. Let's solve #4. If the tests as they are aren't going to be accepted in Tempest then we can put them elsewhere (leave them in keystone (just run differently), move to keystoneclient or a new project). To me this testing has some similarities to Grenade since that involves testing with multiple versions too, so I'll look into how Grenade works.<br>
</div><div><br></div><div>Is testing multiple versions of keystoneclient actually worth it? If the other projects don't feel the need for this then why does Keystone? It's actually caught problems so it's proved useful to Keystone, and we're making changes to the client so this type of testing seems important, but maybe it's not useful enough to continue to do the multiple version testing. If we're going to support backwards compatibility we should test it.<br>
<br></div><div>If we put something together to test multiple versions of keystoneclient would other projects want to use it for their clients?<br></div><div><br></div><div>- Brant<br><br></div></div></div></div></div></div>