[openstack-dev] [tripleo] pingtest vs tempest
ltoscano at redhat.com
Fri May 5 11:00:54 UTC 2017
On Thursday, 4 May 2017 20:11:14 CEST Emilien Macchi wrote:
> On Thu, May 4, 2017 at 9:41 AM, Dan Prince <dprince at redhat.com> wrote:
> > I like the idea of getting pingtest out of tripleo.sh as more of a
> > stand alone tool. I would support an effort that re-implemented it...
> > and using tempest-lib would be totally fine. And as you point out one
> > could even combine these tests with a more common "Tempest" run that
> > incorporates the scenarios, etc.
> I don't understand why we would re-implement the pingtest in a tempest
> plugin. Could you please tell us what is the technical difference between
> what does this scenario :
> And this pingtest:
> They both create a volume Cinder, snapshot it in Glance and and spawn
> a Nova server from the volume.
> What one does that the other one doesn't?
I assumed that you want to exercise that scenario (also) through Heat. If it
is not the case, totally fine, a test like the one that you pointed out works.
> > To me the message is clear that we DO NOT want to consume the normal
> > Tempest scenarios in TripleO upstream CI at this point. Sure there is
> > overlap there, but the focus of those tests is just plain different...
> I haven't seen strong pushback in this thread except you.
> I'm against overlap in general and this one is pretty obvious. Why
> would we maintain a tripleo-specific Tempest scenario while existing
> ones would work for us. Please give me a technical reason in what is
> not good enough in the existing scenarios.
If that scenario is fine, sure. If you want (als) a Heat-based scenario, the
Tempest plugin would contain just that.
> > So ++ for the idea of experimenting with the use of tempest.lib. But
> > stay away from the idea of using Tempest smoke tests and the like for
> > TripleO I think ATM.
> > Its also worth noting there is some risk when maintaining your own in-
> > tree Tempest tests . If I understood that thread correctly that
> > breakage wouldn't have occurred if the stable branch tests were gating
> > Tempest proper... which is a very hard thing to do if we have our own
> > in-tree stuff. So there is a cost to doing what you suggest here, but
> > probably one that we'd be willing to accept.
> I'm not sure we have the resources to write and maintain our own
> in-tree tempest plugin, tbh.
Just a technical note here: apart from the one-time initial setup, as this
hypotetical plugin would basically feed (the existing) heat templates through
an Heat tempest plugin, it would not require a lot of maintainance.
You could argue that a Heat scenario test should go to a Heat Tempest plugin,
but there is another discussion going on right now which shows that this may
be complicated on the Heat side (see "[qa][heat][murano][daisycloud] Removing
Heat support from Tempest").
Again, if the non-Heat existing scenario is fine, you are already covered.
More information about the OpenStack-dev