Open Stack

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
> 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/20140212/0e41f390/attachment.html>