<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 24, 2015 at 9:47 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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Towards the end of merging the regression test for the nova<br>
volume-attach bug - <a href="https://review.openstack.org/#/c/157959/" target="_blank">https://review.openstack.org/#/c/157959/</a> there was a<br>
discussion around what style the functional tests should take.<br>
Especially as that had a mix of CLI and API calls in it.<br></blockquote><div><br></div><div><br></div><div>Thanks for starting this thread.  Once we reach general agreement lets put this in a in tree README for record keeping.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Here are my thoughts for why that test ended up that way:<br>
<br>
1) All resource setup that is table stakes for the test should be done<br>
via the API, regardless if it's a CLI or API test.<br>
<br>
The reason for this is that structured data is returned, which removes<br>
one possible error in the tests by parsing incorrectly. The API objects<br>
returned also include things like .delete methods in most cases, which<br>
means that addCleanup is a little more clean.<br></blockquote><div><br></div><div>IMHO the CLI should have an option to returned raw JSON back instead of pretty tabled results as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
2) Main logic should touch which ever interface you are trying to test.<br>
This was demonstrating a CLI regression, so the volume-attach call was<br>
important to be done over the CLI.<br>
<br>
<br>
Now... here's where theory runs into issues.<br>
<br>
#1 - nova boot is table stakes. Under the above guidelines it should be<br>
called via API. However --poll is a CLI construct and so saved a custom<br>
wait loop here. We should implement that custom wait loop down the road<br>
and make that an API call<br>
<br>
<a href="https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/test_instances.py#L116" target="_blank">https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/test_instances.py#L116</a></blockquote><div><br></div><div>This issue is from a real short coming in the python client. So this isn't really an issue with your theory, just an issue with novaclient.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
#2 - the volume create command is table stakes. It should be an API<br>
call. However, it can't be because the service catalog redirection only<br>
works at the CLI layer. This is actually also the crux of bug #1423695.<br>
The same reason the completion cache code failed is the reason we can't<br>
use the API for that.<br>
<br>
<a href="https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/test_instances.py#L129" target="_blank">https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/test_instances.py#L129</a></blockquote><div><br></div><div>Issues like this are why I wrote the read only nova CLI tests in the first place. Unit testing the python API is doable, but unit testing the CLI is a little bit more tricky. So I expect issues like this to come up over and over again.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
#3 - the cleanup of the volume should have been API call. See reason for #2.<br>
<br>
<a href="https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/test_instances.py#L131" target="_blank">https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/test_instances.py#L131</a><br>
<br>
#4 - the cleanup of the attachment should be an addCleanup via the API.<br>
See reason for #2 why it's not.<br>
<br>
<a href="https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/test_instances.py#L155" target="_blank">https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/test_instances.py#L155</a><br>
<br>
<br>
I'm happy if there are other theories about how we do these things,<br>
being the first functional test in the python-novaclient tree that<br>
creates and destroys real resources, there isn't an established pattern<br>
yet. But I think doing all CLI calls in CLI tests is actually really<br>
cumbersome, especially in the amount of output parsing code needed if<br>
you are going to setup any complicated resource structure.<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>Here is an alternate theory:</div><div><br></div><div>We should have both python API and CLI functional tests. But they should be kept separate.</div><div><br></div><div>This is to help us make sure both the CLI and python API are actually usable interfaces. As the exercise above has shown, they both have really major short comings.  I think having in tree functional testing covering both the CLI and python API will make it easier for us to review new client features in terms of usability.</div><div><br></div><div>Here is a very rough proof of concept patch showing the same tests: <a href="https://review.openstack.org/#/c/157974/2/novaclient/tests/functional/test_volumes.py,cm">https://review.openstack.org/#/c/157974/2/novaclient/tests/functional/test_volumes.py,cm</a></div><div><br></div><div>No matter how we define this functional testing model, I think its clear novaclient needs a decent amount of work before it can really be usable.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><font color="#888888">
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>