[openstack-dev] [qa][tempest][rally] Rally & Tempest integration: tempest.conf autogeneration

Sean Dague sean at dague.net
Wed Feb 12 22:55:13 UTC 2014


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

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 547 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140212/3b87901a/attachment.pgp>


More information about the OpenStack-dev mailing list