<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 4, 2017 at 7:13 PM Emilien Macchi <<a href="mailto:emilien@redhat.com">emilien@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 4, 2017 at 9:41 AM, Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>> wrote:<br>
> On Thu, 2017-05-04 at 03:11 -0400, Luigi Toscano wrote:<br>
>> ----- Original Message -----<br>
>> > On Wed, 2017-05-03 at 17:53 -0400, Emilien Macchi wrote:<br>
>> > > (cross-posting)<br>
>> ><br>
>> > > Instead of running the Pingtest, we would execute a Tempest<br>
>> > > Scenario<br>
>> > > that boot an instance from volume (like Pingstest is already<br>
>> > > doing)<br>
>> > > and see how it goes (in term of coverage and runtime).<br>
>> > > I volunteer to kick-off the work with someone more expert than I<br>
>> > > am<br>
>> > > with quickstart (Arx maybe?).<br>
>> > ><br>
>> > > Another iteration could be to start building an easy interface to<br>
>> > > select which Tempest tests we want a TripleO CI job to run and<br>
>> > > plug<br>
>> > > it<br>
>> > > to our CI tooling (tripleo-quickstart I presume).<br>
>> ><br>
>> > Running a subset of Tempest tests isn't the same thing as designing<br>
>> > (and owning) your own test suite that targets the things that mean<br>
>> > the<br>
>> > most to our community (namely speed and coverage). Even giving up<br>
>> > 5-10<br>
>> > minutes of runtime...just to be able to run Tempest isn't something<br>
>> > that some of us would be willing to do.<br>
>><br>
>> As I mentioned, you can do it with Tempest (the library). You can<br>
>> have your own test suite that does exactly what you are asking<br>
>> (namely, a set of scenario tests based on Heat which targets the<br>
>> TripleO use case) in a Tempest plugin and there is no absolute reason<br>
>> that those tests should add 5-10 minutes of runtime compared to<br>
>> pingtest.<br>
>><br>
>> It/they would be exactly pingtest, only implemented using a different<br>
>> library and running with a different runner, with the *exact* same<br>
>> run time.<br>
>><br>
>> Obvious advantages: only one technology used to run tests, so if<br>
>> anyone else want to run additional tests, there is no need to<br>
>> maintain two code paths; reuse on a big and proven library of test<br>
>> and test runner tools.<br>
><br>
> I like the idea of getting pingtest out of tripleo.sh as more of a<br>
> stand alone tool. I would support an effort that re-implemented it...<br>
> and using tempest-lib would be totally fine. And as you point out one<br>
> could even combine these tests with a more common "Tempest" run that<br>
> incorporates the scenarios, etc.<br>
<br>
I don't understand why we would re-implement the pingtest in a tempest plugin.<br>
Could you please tell us what is the technical difference between what<br>
does this scenario :<br>
<a href="https://github.com/openstack/tempest/blob/master/tempest/scenario/test_volume_boot_pattern.py" rel="noreferrer" target="_blank">https://github.com/openstack/tempest/blob/master/tempest/scenario/test_volume_boot_pattern.py</a><br>
<br>
And this pingtest:<br>
<a href="https://github.com/openstack/tripleo-heat-templates/blob/master/ci/pingtests/tenantvm_floatingip.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/ci/pingtests/tenantvm_floatingip.yaml</a><br>
<br>
They both create a volume Cinder, snapshot it in Glance and and spawn<br>
a Nova server from the volume.<br>
<br>
What one does that the other one doesn't?<br>
<br>
> To me the message is clear that we DO NOT want to consume the normal<br>
> Tempest scenarios in TripleO upstream CI at this point. Sure there is<br>
> overlap there, but the focus of those tests is just plain different...<br>
<br>
I haven't seen strong pushback in this thread except you.<br>
I'm against overlap in general and this one is pretty obvious. Why<br>
would we maintain a tripleo-specific Tempest scenario while existing<br>
ones would work for us. Please give me a technical reason in what is<br>
not good enough in the existing scenarios.<br>
<br>
> speed isn't a primary concern there as it is for us so I don't think we<br>
> should do it now. And probably not ever unless the CI job time is less<br>
> than an hour. Like even if we were able to tune a set of stock Tempest<br>
> smoke tests today to our liking unless TripleO proper gates on the<br>
> runtime of those not increasing we'd be at risk of breaking our CI<br>
> queues as the wall time would potentially get too long. In this regard<br>
> this entire thread is poorly named I think in that we are no longer<br>
> talking about 'pingtest vs. tempest' but rather the implementation<br>
> details of how we reimplement our existing pingtest to better suite the<br>
> community.<br>
<br>
What I would like to see if we're going to use Tempest in our gate, is<br>
to run at least one TripleO jobs as voting in Tempest.<br>
<br>
Tempest folks: I need your support here. We have been running Puppet<br>
jobs as non-voting and we have seen a quite number of patches that<br>
broke us because folks were ignore the jobs. If we switch TripleO to<br>
use more Tempest, being in your gate might be required. We'll run the<br>
fastest and  more stable job that we have to make sure the impact for<br>
you is minimal.<br>
<br></blockquote><div><br></div><div><div>For TripleO I guess the risks of failures might be about deploying tempest</div><div>tests and their dependencies more than else.  </div></div><div><br></div><div>We're increasing our stable API surface constantly, and I believe the number</div><div>of breakages have decreased over time - I don't have data to support this though.</div><div><br></div><div>From a test pov, any cloud deployed by TripleO should be able to run a few</div><div>basic scenarios and I would say the likelihood of Tempest breaking that is rather</div><div>low. </div><div><br></div><div>We could start with a non-voting job like for puppet and take it from there.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> So ++ for the idea of experimenting with the use of tempest.lib. But<br>
> stay away from the idea of using Tempest smoke tests and the like for<br>
> TripleO I think ATM.<br>
><br>
> Its also worth noting there is some risk when maintaining your own in-<br>
> tree Tempest tests [1]. If I understood that thread correctly that<br>
> breakage wouldn't have occurred if the stable branch tests were gating<br>
> Tempest proper... which is a very hard thing to do if we have our own<br>
> in-tree stuff. So there is a cost to doing what you suggest here, but<br>
> probably one that we'd be willing to accept.<br>
<br>
I'm not sure we have the resources to write and maintain our own<br>
in-tree tempest plugin, tbh.<br>
<br>
> [1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-May/116172" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2017-May/116172</a>.<br>
> html<br>
><br>
> Dan<br>
><br>
<br>
It sounds like we haven't reached full consensus yet but at least we<br>
agreed on experimenting with Tempest.<br>
<br>
While we make progress on the discussion, I'll start working with some<br>
folks as experimental jobs, so we can make progress in the meantime.<br>
<br>
Thanks,<br>
--<br>
Emilien Macchi<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>