Open Stack

Responses inline.

On Mon, Dec 9, 2013 at 10:07 AM, Sean Dague <sean at dague.net> wrote:

> On 12/09/2013 10:12 AM, Brant Knudson wrote:
> > Monty -
> >
> > Thanks for doing the work already to get the infrastructure set up.
> > Looks like I've got the easy part here. I posted an initial patch that
> > has one test from keystone in https://review.openstack.org/#/c/60724/ .
> > I hope to be able to move all the tests over unchanged. The tricky part
> > is getting all the fixtures set up the same way that keystone does.
>
> I think a direct port of the keystone fixtures is the wrong approach.
> These really need to act more like the scenario tests that exist over
> there. And if the intent is just a dump of the keystone tests we need to
> step back... because that's not going to get accepted.
>
>
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.

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.

I actually think that we should solve #4 first - how you test the thing
> you actually want to test in the gate. Which is about getting
> devstack-gate to setup the world that you want to test. I really think
> the location of the tests all flow from there. Because right now it
> seems like the cart is before the horse.
>
>
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.

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.

If we put something together to test multiple versions of keystoneclient
would other projects want to use it for their clients?

- Brant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131209/db48b716/attachment.html>