<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 5, 2014 at 2:40 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 09/04/2014 11:32 AM, Steven Hardy wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Thu, Sep 04, 2014 at 10:45:59AM -0400, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 08/29/2014 05:15 PM, Zane Bitter wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 29/08/14 14:27, Jay Pipes wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 08/26/2014 10:14 AM, Zane Bitter wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Steve Baker has started the process of moving Heat tests out of the<br>
Tempest repository and into the Heat repository, and we're looking for<br>
some guidance on how they should be packaged in a consistent way.<br>
Apparently there are a few projects already packaging functional tests<br>
in the package <projectname>.tests.functional (alongside<br>
<projectname>.tests.unit for the unit tests).<br>
<br>
That strikes me as odd in our context, because while the unit tests run<br>
against the code in the package in which they are embedded, the<br>
functional tests run against some entirely different code - whatever<br>
OpenStack cloud you give it the auth URL and credentials for. So these<br>
tests run from the outside, just like their ancestors in Tempest do.<br>
<br>
There's all kinds of potential confusion here for users and packagers.<br>
None of it is fatal and all of it can be worked around, but if we<br>
refrain from doing the thing that makes zero conceptual sense then there<br>
will be no problem to work around :)<br>
<br>
I suspect from reading the previous thread about "In-tree functional<br>
test vision" that we may actually be dealing with three categories of<br>
test here rather than two:<br>
<br>
* Unit tests that run against the package they are embedded in<br>
* Functional tests that run against the package they are embedded in<br>
* Integration tests that run against a specified cloud<br>
<br>
i.e. the tests we are now trying to add to Heat might be qualitatively<br>
different from the <projectname>.tests.functional suites that already<br>
exist in a few projects. Perhaps someone from Neutron and/or Swift can<br>
confirm?<br>
<br>
I'd like to propose that tests of the third type get their own top-level<br>
package with a name of the form <projectname>-integrationtests (second<br>
choice: <projectname>-tempest on the principle that they're essentially<br>
plugins for Tempest). How would people feel about standardising that<br>
across OpenStack?<br>
</blockquote>
<br>
By its nature, Heat is one of the only projects that would have<br>
integration tests of this nature. For Nova, there are some "functional"<br>
tests in nova/tests/integrated/ (yeah, badly named, I know) that are<br>
tests of the REST API endpoints and running service daemons (the things<br>
that are RPC endpoints), with a bunch of stuff faked out (like RPC<br>
comms, image services, authentication and the hypervisor layer itself).<br>
So, the "integrated" tests in Nova are really not testing integration<br>
with other projects, but rather integration of the subsystems and<br>
processes inside Nova.<br>
<br>
I'd support a policy that true integration tests -- tests that test the<br>
interaction between multiple real OpenStack service endpoints -- be left<br>
entirely to Tempest. Functional tests that test interaction between<br>
internal daemons and processes to a project should go into<br>
/$project/tests/functional/.<br>
<br>
For Heat, I believe tests that rely on faked-out other OpenStack<br>
services but stress the interaction between internal Heat<br>
daemons/processes should be in /heat/tests/functional/ and any tests the<br>
rely on working, real OpenStack service endpoints should be in Tempest.<br>
</blockquote>
<br>
Well, the problem with that is that last time I checked there was<br>
exactly one Heat scenario test in Tempest because tempest-core doesn't<br>
have the bandwidth to merge all (any?) of the other ones folks submitted.<br>
<br>
So we're moving them to openstack/heat for the pure practical reason<br>
that it's the only way to get test coverage at all, rather than concerns<br>
about overloading the gate or theories about the best venue for<br>
cross-project integration testing.<br>
</blockquote>
<br>
Hmm, speaking of passive aggressivity...<br>
<br>
Where can I see a discussion of the Heat integration tests with Tempest QA<br>
folks? If you give me some background on what efforts have been made already<br>
and what is remaining to be reviewed/merged/worked on, then I can try to get<br>
some resources dedicated to helping here.<br>
</blockquote>
<br>
We recieved some fairly strong criticism from sdague[1] earlier this year,<br>
at which point we were  already actively working on improving test coverage<br>
by writing new tests for tempest.<br>
<br>
Since then, several folks, myself included, commited very significant<br>
amounts of additional effort to writing more tests for tempest, with some<br>
success.<br>
<br>
Ultimately the review latency and overhead involved in constantly rebasing<br>
changes between infrequent reviews has resulted in slow progress and<br>
significant frustration for those attempting to contribute new test cases.<br>
<br>
It's been clear for a while that tempest-core have significant bandwidth<br>
issues, as well as not necessarily always having the specific domain<br>
expertise to thoroughly review some tests related to project-specific<br>
behavior or functionality.<br>
<br>
So it was with some relief that we saw the proposal[2] to move the burden<br>
for reviewing project test-cases to the project teams, who will presumably<br>
be more motivated to do the reviews, and have the knowledge of what needs<br>
testing.<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-March/029661.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>March/029661.html</a><br>
[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>July/041057.html</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would greatly prefer just having a single source of integration testing in<br>
OpenStack, versus going back to the bad ol' days of everybody under the sun<br>
rewriting their own.<br>
<br>
Note that I'm not talking about functional testing here, just the<br>
integration testing...<br>
</blockquote>
<br>
You may have to define the terms functional and integration here, as IMO<br>
there's already significant confusion about what the target of e.g API and<br>
scenario tests in tempest are.<br>
</blockquote>
<br></div></div>
Yes, I already did this in a previous (snipped) portion of this email thread. See here:<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-August/044514.html" target="_blank">http://lists.openstack.org/<u></u>pipermail/openstack-dev/2014-<u></u>August/044514.html</a><br>
<br>
yay for multi-month-crossing ML threads ;)<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is also further complicated by the fact that all heat functional tests<br>
also test integration of the various underlying services to some extent.<br>
</blockquote>
<br></div>
Yes, as acknowledged in above post -- but Heat is special in this regard, as mentioned in the post above. Functional tests for Heat are not the same as functional tests for Nova, Keystone, Glance, Swift, etc.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My opinion is that any tests remaining in tempest should focus on API<br>
correctness, e.g to keep us honest in terms of backwards incomaptible<br>
changes to the API surface.<br>
</blockquote>
<br></div>
OK, that's a perfectly reasonable suggestion. Would the Heat functional^Wintegration tests then only test the latest version of the APIs?<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Then for all tests which aim to prove the functionality of the project, e.g<br>
my understanding of tempest scenario tests atm, we should allow project<br>
teams to own them, and add to them as functionality develops over time.<br>
</blockquote>
<br></div>
Well, that's where things get interesting. Functional tests in Glance and Nova, for instance, are functional tests, not integration tests, because they specifically do NOT test things like authentication -- i.e. the interaction between Nova/Glance and Keystone. The Nova functional tests likewise do not test the interaction between Nova and Glance, nor Nova and the underlying hypervisor, as those layers are both faked out in the functional Nova tests.<br>

<br>
As I mentioned in the above post, though, Heat is different. In order for Heat to really have a worthwhile functional test, it would have to fake out every single OpenStack service, since Heat itself does little more than provide an </blockquote>
<div><br></div><div>This might be possible:-O<br></div><div><br></div><div>Check out:<br><a href="https://openstacksummitnovember2014paris.sched.org/event/78969d086807fb8f60b29142149d9163#.VAka3da5s1w">https://openstacksummitnovember2014paris.sched.org/event/78969d086807fb8f60b29142149d9163#.VAka3da5s1w</a><br>
<a href="https://github.com/rackerlabs/mimic">https://github.com/rackerlabs/mimic</a><br></div><div><br></div><div>It would be neat to have a "fakestack" that heat (and others) could use.<br><br></div><div>Then we run our functional tests against fakestack and the integration tests run the same tests just with a real<br>
</div><div>devstack backing it.<br><br></div><div>-Angus<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">orchestration REST API and template format that itself calls other OpenStack services. And it is for this reason that I believe functional tests for Heat belong in Tempest, since Tempest tests assume a working OpenStack environment already, and there's no reason to either fake out all the OpenStack services, nor any reason to develop a separate integration testing framework inside of Heat that does the same things that Tempest does.<br>

<br>
For Glance functional tests, they are testing the communication channels between the Glance API service and the Glance registry service. For Nova functional tests, they are testing the communication channels between the Nova API, Nova conductor, Nova scheduler and Nova compute services.<br>

<br>
Heat does not have these internal interfaces to test communications for, and this is why I don't think an in-Heat-tree functional test suite is worth bothering with versus the (yes, frustrating) process of adding tempest Heat tests.<br>

<br>
Best,<br>
-jay<div class=""><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ultimately I don't think it really matters which repo those tests live in,<br>
provided we can write them and get them running in the gate (catching<br>
regressions, which otherwise keep slipping through) in a timely manner.<br>
<br>
Steve<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>