<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 10, 2014 at 4:23 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">As I've been staring at failures in the gate a lot over the past month,<br>


we've managed to increasingly tune the tempest client for readability<br>
and debugability. So when something fails in an API test, pin pointing<br>
it's failure point is getting easier. The scenario tests... not so much.<br>
<br>
Using the official clients in the scenario tests was originally thought<br>
of as a way to get some extra testing on those clients through Tempest.<br>
However it has a ton of debt associated with it. And I think that client<br>
testing should be done as functional tests in the client trees[1], not<br>
as a side effect of Tempest. </blockquote><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>
 * It makes the output of a fail path radically different between the 2<br>
types<br>
 * It adds a bunch of complexity on tenant isolation (and basic<br>
duplication between building accounts for both clients)<br>
 * It generates a whole bunch of complexity around "waiting for"<br>
resources, and safe creates which garbage collect. All of which has to<br>
be done above the client level because the official clients don't<br>
provide that functionality.<br>
<br>
In addition the official clients don't do the right thing when hitting<br>
API rate limits, so are dubious in running on real clouds. There was a<br>
proposed ugly monkey patch approach which was just too much for us to<br>
deal with.</blockquote><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>
Migrating to tempest clients I think would clean up a ton of complexity,<br>
and provide for a more straight forward debuggable experience when using<br>
Tempest.<br>
<br>
I'd like to take a temperature on this though, so comments welcomed.<br>
<br></blockquote><div><br></div><div><div>While I understand the big short term value of moving to the tempest clients instead of the official clients. I am concerned about what that implies for the official clients; they are so bad even we don't want to use them. Moving away from the official clients sort of sounds like we are giving up on them without any plan to improve them.</div>

</div><div><br></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">
        -Sean<br>
<br>
[1] -<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/039733.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-July/039733.html</a><br>
(see New Thinking about our validation layers)<br>
<span class=""><font color="#888888"><br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
<br></blockquote></div><br></div></div>