<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 4, 2017 at 11:11 PM Dan Prince <<a href="mailto:dprince@redhat.com">dprince@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, 2017-05-04 at 14:11 -0400, Emilien Macchi wrote:<br>
> On Thu, May 4, 2017 at 9:41 AM, Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>><br>
> 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>
> > > > > 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<br>
> > > > > than I<br>
> > > > > am<br>
> > > > > with quickstart (Arx maybe?).<br>
> > > > ><br>
> > > > > Another iteration could be to start building an easy<br>
> > > > > interface to<br>
> > > > > select which Tempest tests we want a TripleO CI job to run<br>
> > > > > 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<br>
> > > > designing<br>
> > > > (and owning) your own test suite that targets the things that<br>
> > > > mean<br>
> > > > the<br>
> > > > most to our community (namely speed and coverage). Even giving<br>
> > > > up<br>
> > > > 5-10<br>
> > > > minutes of runtime...just to be able to run Tempest isn't<br>
> > > > 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<br>
> > > 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<br>
> > > different<br>
> > > library and running with a different runner, with the *exact*<br>
> > > 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<br>
> > > 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<br>
> > it...<br>
> > and using tempest-lib would be totally fine. And as you point out<br>
> > one<br>
> > could even combine these tests with a more common "Tempest" run<br>
> > that<br>
> > incorporates the scenarios, etc.<br>
><br>
> I don't understand why we would re-implement the pingtest in a<br>
> tempest plugin.<br>
> Could you please tell us what is the technical difference between<br>
> what<br>
> does this scenario :<br>
> <a href="https://github.com/openstack/tempest/blob/master/tempest/scenario/tes" rel="noreferrer" target="_blank">https://github.com/openstack/tempest/blob/master/tempest/scenario/tes</a><br>
> t_volume_boot_pattern.py<br>
><br>
> And this pingtest:<br>
> <a href="https://github.com/openstack/tripleo-heat-templates/blob/master/ci/pi" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-heat-templates/blob/master/ci/pi</a><br>
> ngtests/tenantvm_floatingip.yaml<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>
I don't think these are the same things. Does the Tempest test even<br>
create a floating IP? And in the case of pingtest we also cover Heat<br>
API in the overcloud (also valuable coverage). And even if they could<br>
be made to match today is there any guarantee that they would diverge<br>
in the future or maintain the same speed goals as that test lives in<br>
Tempest (and most TripleO cores don't review there).<br>
<br>
The main difference that I care about is it is easier for us to<br>
maintain and fix the pingtest varient at this point. We care a lot<br>
about our CI, and like I said before increasing the runtime isn't<br>
something we could easily tolerate. I'm willing to entertain reuse so<br>
long as it also allows us the speed and control we desire.<br>
<br>
><br>
> > To me the message is clear that we DO NOT want to consume the<br>
> > normal<br>
> > Tempest scenarios in TripleO upstream CI at this point. Sure there<br>
> > is<br>
> > overlap there, but the focus of those tests is just plain<br>
> > different...<br>
><br>
> I haven't seen strong pushback in this thread except you.<br>
<br>
Perhaps most cores haven't weighed in on this issue because moving to<br>
Tempest(-lib) isn't the most pressing issue ATM. We have a lot of<br>
architectural changes happening at the moment for example and that is<br>
why I only replied to this thread this week.<br>
<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>
We maintain it because we care about speed I think. </blockquote><div><br></div><div>We (QA) care about speed as well :) </div><div><br></div><div>Even when deploying with devstack, we are rather resource and time</div><div>contained. Granted, not to the level of TripleO perhaps.</div><div>We use a "slow" tag to mark tests that take longer to run, which could</div><div>be useful for you as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, the re-use<br>
you talk about here has a fairly large cost to us in that we'd be<br>
introducing new dependencies and code reviews for TripleO. All of this<br>
has a cost too... when it really comes down to it I think the simpler<br>
implementation of ping test suites what we do and need in TripleO quite<br>
fine already.<br>
<br>
My assumption was that some of the people chiming into this thread<br>
would do the heavy lifting to give us a tempest.lib parity test that<br>
covers the same things we do today (in a similar runtime). Call it an<br>
experiment I guess... just to see what it would look like if we went<br>
down this path. If it works out... and everyone likes it great. If not<br>
then perhaps we still keep some of the simplicity we have today with<br>
pingtest. But I'm still not convinced that this test lives in Tempest<br>
proper because then we'd loose our guarantees of speed (runtime) and<br>
coverage as it is out of our control.<br>
<br>
Dan<br>
<br>
<br>
><br>
> > speed isn't a primary concern there as it is for us so I don't<br>
> > think we<br>
> > should do it now. And probably not ever unless the CI job time is<br>
> > less<br>
> > than an hour. Like even if we were able to tune a set of stock<br>
> > 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<br>
> > 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<br>
> > the<br>
> > community.<br>
><br>
> What I would like to see if we're going to use Tempest in our gate,<br>
> 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>
> > So ++ for the idea of experimenting with the use of tempest.lib.<br>
> > But<br>
> > stay away from the idea of using Tempest smoke tests and the like<br>
> > for<br>
> > TripleO I think ATM.<br>
> ><br>
> > Its also worth noting there is some risk when maintaining your own<br>
> > 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<br>
> > gating<br>
> > Tempest proper... which is a very hard thing to do if we have our<br>
> > own<br>
> > in-tree stuff. So there is a cost to doing what you suggest here,<br>
> > 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/116" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2017-May/116</a><br>
> > 172.<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<br>
> some<br>
> folks as experimental jobs, so we can make progress in the meantime.<br>
><br>
> Thanks,<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>