Open Stack

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 :
> https://github.com/openstack/tempest/blob/master/tempest/scenario/test_volum
> e_boot_pattern.py
> 
> And this pingtest:
> https://github.com/openstack/tripleo-heat-templates/blob/master/ci/pingtests
> /tenantvm_floatingip.yaml
> 
> 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 [1]. 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.

Ciao
-- 
Luigi