On 4 July 2013 04:19, Christopher Armstrong <[email protected]>wrote:
> On Tue, Jul 2, 2013 at 11:38 PM, Robert Collins > <[email protected]> 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 <[email protected]> Distinguished Technologist HP Cloud Services
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
