+1 for decoupling Tempest from devstack
Openstack deployment tool is TripleO / Heat -so it would be good to have an Heat template to deploy and configure Tempest andrea From: David Kranz [mailto:dkr...@redhat.com] Sent: 12 February 2014 23:23 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [qa][tempest][rally] Rally & Tempest integration: tempest.conf autogeneration On 02/12/2014 05:55 PM, Sean Dague wrote: On 02/12/2014 05:08 PM, Boris Pavlovic wrote: Hi all, It goes without saying words that actually tempest[1] is only one public known tool that could fully verify deployments and ensure dthat they work. In Rally[2] we would like to use it as a cloud verifier (before benchmarking it is actually very useful;) to ensure that cloud work). We are going to build on top of tempest pretty interface and aliases & support of working with different clouds. E.g.: rally use deployment <uuid> # use some deployment that is registered in Rally rally verify nova # Run only nova tests against `in-use` deployment rally verify small/big/full # set of tests rally verify list # List all verification results for this deployment rally verify show <id> # Show detailed information # Okay we found that something failed, fixed it in cloud, restart service and we would like you to run only failed tests rally verify latest_failed # do it in one simple command These commands should be very smart, generate proper tempest.conf for specific cloud, prepare cloud for tempest testing, store somewhere results and so on and so on. So at the end we will have very simple way to work with tempest. We added first patch that adds base functionality to Rally [3]: https://review.openstack.org/#/c/70131/ At QA meeting I discussed it with David Kranz, as a result we agree that part of this functionality (tempest.conf generator & cloud prepare), should be implemented inside tempest. Current situation is not super cool because, there are at least 4 projects where we are generating in different way tempest.conf: 1) DevStack 2) Fuel CI 3) Rally 4) Tempest (currently broken) To put it in a nutshell, it's clear that we should make only 1 tempest.conf generator [4], that will cover all cases, and will be enough simple to be used in all other projects. So in the past the issue was we could never get anyone to agree on one. For instance, devstack makes some really fine grained decisions, and the RDO team showed up with a very different answer file approach, which wouldn't work for devstack (it had the wrong level of knob changing). And if the end of the day you replace build a tempest config generator, which takes 200 options, I'm not entirely sure how that was better than just setting those 200 options directly. So while happy to consider options here, realize that there is a reason this has been punted before. -Sean I have thought about this and think we can do better. I will present a spec when I get a chance if no one else does. I would leave devstack out of it, at least for now. In general it would be good to decouple tempest from devstack a little more, especially as it gains wider use in rally, refstack, etc. For example, there are default paths and stuff in tempest.conf.sample that refer to files that are only put there by devstack. -David _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
