<div class="gmail_quote">On 4 July 2013 04:19, Christopher Armstrong <span dir="ltr"><<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@rackspace.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="HOEnZb"><div class="h5">On Tue, Jul 2, 2013 at 11:38 PM, Robert Collins<br>
<<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
> Radix points out I missed the naunce that you're targeting the users<br>
> of python-novaclient, for instance, rather than python-novaclient's<br>
> own tests.<br>
><br>
><br>
</div></div></blockquote><div>... <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> So it seems to me that a fast server fake can be used in tests of<br>

> python-novaclient, *and* in tests of code using python-novaclient<br>
> (including for instance, heat itself), and we get to write it just<br>
> once per server, rather than once per server per language binding.<br>
><br>
> -Rob<br>
<br>
<br>
</div></div>I want to make sure I understond you. Let's say I have a program named<br>
cool-cloud-tool, and it uses python-novaclient, python-keystoneclient,<br>
and three other clients for OpenStack services. You're suggesting that<br>
its test suite should start up instances of all those OpenStack<br>
services with in-memory or otherwise localized backends, and<br>
communicate with them using standard python-*client functionality?<br></blockquote><div><br>Yes.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can imagine that being a useful thing, if it's very easy to do, and<br>
won't increase my test execution time too much.</blockquote><div><br>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.<br>
<br>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.<br>
<br>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:<br>
 a) make a nova API call<br> b) wait for the 'instance to boot'<br> c) check that the expected API calls were made<br><br>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.<br>
<br>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.<br><br>-Rob<br></div></div><br>-- <br>Robert Collins <<a href="mailto:rbtcollins@hp.com" target="_blank">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>HP Cloud Services