On Thursday, 4 May 2017 20:11:14 CEST Emilien Macchi wrote: > On Thu, May 4, 2017 at 9:41 AM, Dan Prince <dpri...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
