Open Stack

On 4 July 2013 04:19, Christopher Armstrong
<chris.armstrong at rackspace.com>wrote:

> On Tue, Jul 2, 2013 at 11:38 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
> > Radix points out I missed the naunce that you're targeting the users
> > of python-novaclient, for instance, rather than python-novaclient's
> > own tests.
> >
> >
>
...

> > So it seems to me that a fast server fake can be used in tests of
> > python-novaclient, *and* in tests of code using python-novaclient
> > (including for instance, heat itself), and we get to write it just
> > once per server, rather than once per server per language binding.
> >
> > -Rob
>
>
> I want to make sure I understond you. Let's say I have a program named
> cool-cloud-tool, and it uses python-novaclient, python-keystoneclient,
> and three other clients for OpenStack services. You're suggesting that
> its test suite should start up instances of all those OpenStack
> services with in-memory or otherwise localized backends, and
> communicate with them using standard python-*client functionality?
>

Yes.


> I can imagine that being a useful thing, if it's very easy to do, and
> won't increase my test execution time too much.


In bzr's test suite we found that such tests (using a non-encrypted plain
socket to talk to servers, rather than mock objects) was plenty fast:
slowness in the test suite occurred in tests that did a lot of actual vcs
operations - it's the lower layers that needed chopping out.

I think it's important to draw a distinction between what Joe Gordon is
suggesting and what I'm suggesting: nova operations are 10's to 100's of ms
today. I'm talking about a lightweight server that responds in single-digit
ms.

Consider a simple API call - say nova boot. Right now that has a good half
dozen rabbit RPC calls: API hands off work which is then done done
asynchronously: scheduler, neutron, compute, keystone once keypairs live
there, cinder and glance. It's a *lot* of work which isn't useful for
cool-cloud-tool, which just wants in it's test suite to:
 a) make a nova API call
 b) wait for the 'instance to boot'
 c) check that the expected API calls were made

a and b should be no more than a couple ms apart in a test server; (c) is
specific to a test server and not a use case the production server /should/
implement.

So while today the fake virt backend for nova exists, its still too far
down the stack to deliver the sort of story I'm talking about.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130705/8eb64f11/attachment.html>