<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 30, 2014 at 6:30 AM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.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"><br>
<br>
> Hi everyone,<br>
><br>
> Before we start the larger discussion at summit next week about the future of<br>
> testing in OpenStack - specifically about spinning up functional testing and<br>
> how<br>
> it relates to tempest - I would like to share some of my thoughts on how we<br>
> can<br>
> get things started and how I think they'll eventually come together.<br>
><br>
> Currently in tempest we have a large number of tests (mostly api-focused)<br>
> which are probably a better fit for a project's functional test suite. The<br>
> best<br>
> example I can think of is the nova flavors tests. Validation of flavor<br>
> manipulation doesn't need to run in the integrated test suite on every commit<br>
> to<br>
> every project because it only requires Nova. A simple win for initiating<br>
> in-tree<br>
> functional testing would be to move these kinds of tests into the projects<br>
> and<br>
> run the tests from the project repos instead of from tempest.<br>
><br>
> This would have the advantage of making tempest slimmer for every project<br>
> and begin the process of getting projects to take responsibility for their<br>
> functional testing rather than relying on tempest. As tests are moved tempest<br>
> can start to become the integration test suite it was meant to be. It would<br>
> retain only tests that involve multiple projects and stop being the OpenStack<br>
> black box testing suite. I think that this is the right direction for tempest<br>
> moving forward, especially as we move to having project-specific functional<br>
> testing.<br>
><br>
> Doing this migration is dependent on some refactors in tempest and moving<br>
> the required bits to tempest-lib so they can be easily consumed by the<br>
> other projects. This will be discussed at summit, is being planned<br>
> for implementation this cycle, and is similar to what is currently in<br>
> progress<br>
> for the cli tests.<br>
><br>
> The only reason this testing existed in tempest in the first place was as<br>
> mechanism to block and then add friction against breaking api changes.<br>
> Tempest's<br>
> api testing has been been pretty successful at achieving these goals. We'll<br>
> want<br>
> to ensure that migrated tests retain these characteristics. If we are using<br>
> clients from tempest-lib we should get this automatically since to break<br>
> the api you'd have to change the api client. Another option proposed was to<br>
> introduce a hacking rule that would block changes to api tests at the same<br>
> time<br>
> other code was being changed.<br>
><br>
> There is also a concern for external consumers of tempest if we move the<br>
> tests<br>
> out of the tempest tree (I'm thinking refstack). I think the solution is<br>
> to maintain a load_tests discovery method inside of tempest or elsewhere that<br>
> will run the appropriate tests from the other repos for something like<br>
> refstack.<br>
> Assuming that things are built in a compatible way using the same framework<br>
> then<br>
> running the tests from separate repos should be a simple matter of pointing<br>
> the<br>
> test runner in the right direction.<br>
><br>
> I also want to comment on the role of functional testing. What I've proposed<br>
> here is only one piece of what project specific functional testing should be<br>
> and just what I feel is a good/easy start. I don't feel that this should be<br>
> the only testing done in the projects.  I'm suggesting this as a first<br>
> step because the tests already exist and it should be a relatively simple<br>
> task.<br>
> I also feel that using tempest-lib like this shouldn't be a hard requirement.<br>
> Ideally the client definitions shouldn't have to live externally, or if they<br>
> did<br>
> they would be the official clients, but I am suggesting this as a first step<br>
> to<br>
> start a migration out of tempest.<br>
><br>
> I don't want anyone to feel that they need block their functional testing<br>
> efforts until tempest-lib becomes more useable. The larger value from<br>
> functional<br>
> testing is actually in enabling testing more tightly coupled to the projects<br>
> (e.g. whitebox testing). I feel that any work necessary to enable functional<br>
> testing should be prioritized.<br>
<br>
</div></div>Thanks Matt for getting the ball rolling on this conversation in advance<br>
of summit.<br>
<br>
Probably stating the obvious here, but I feel we should make a concious<br>
effort to keep the approaches to in-tree functional testing as consistent<br>
as possible across projects.<br>
<br>
Towards that end, it would be good for folks with an interest in this area<br>
to attend each other's sessions where possible:<br>
<br></blockquote><div> </div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Cross-project: Tue, 12:05 [1]<br>
 Heat:          Wed, 13:50 [2]<br>
 Nova:          Wed, 16:30 [3]<br>
 Ceilometer:    Wed, 17:20 [4]<br>
 QA:            Wed, 17:20 [5] </blockquote><div><br></div><div>I think Keystone was planning on dedicating some time to this on Friday, so our dev/hackathon day. I'm </div><div>interested in the process that will be in place for tracking status of the "functional test migration" if there will be one. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unfortunately there's a clash there between the QA tempest-lib session<br>
and the ceilo session. I'm not sure how reasonable it would be to make<br>
a last-minute schedule change to avoid that clash.<br>
<br>
Cheers,<br>
Eoghan<br>
<br>
[1] <a href="http://kilodesignsummit.sched.org/event/575938e4837e8293615845582d7e3e7f" target="_blank">http://kilodesignsummit.sched.org/event/575938e4837e8293615845582d7e3e7f</a><br>
[2] <a href="http://kilodesignsummit.sched.org/event/eb261fb08b18ec1eaa2c67492e7fc385" target="_blank">http://kilodesignsummit.sched.org/event/eb261fb08b18ec1eaa2c67492e7fc385</a><br>
[3] <a href="http://kilodesignsummit.sched.org/event/271a9075c1ced6c1269100ff4b8efc37" target="_blank">http://kilodesignsummit.sched.org/event/271a9075c1ced6c1269100ff4b8efc37</a><br>
[4] <a href="http://kilodesignsummit.sched.org/event/daf63526a1883e84cec107c70cc6cad3" target="_blank">http://kilodesignsummit.sched.org/event/daf63526a1883e84cec107c70cc6cad3</a><br>
[5] <a href="http://kilodesignsummit.sched.org/event/a45e9af23c2c3fc17c12cc22e8bb3704" target="_blank">http://kilodesignsummit.sched.org/event/a45e9af23c2c3fc17c12cc22e8bb3704</a><br>
<div class="HOEnZb"><div class="h5"><br>
<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>
</div></div></blockquote></div><br></div></div>