Open Stack

+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:dkranz at 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 at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/96c52c2b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6199 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/96c52c2b/attachment.bin>