Open Stack

Hi David,

> -----Original Message-----
> From: David Kranz [mailto:dkranz at redhat.com]
> Sent: Friday, May 02, 2014 2:30 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] Branchless Tempest QA Spec - final draft
> 
> > The verify_tempest_config tool was an attempt at a compromise between being
> > explicit and also using auto discovery. By using the APIs to help create a
> > config file that reflected the current configuration state of the services. It's
> > still a WIP though, and it's really just meant to be a user tool. I don't ever
> > see it being included in our gate workflow.
>
> I think we have to accept that there are two legitimate use cases for
> tempest configuration:
> 
> 1. The entity configuring tempest is the same as the entity that
> deployed. This is the gate case.
> 2. Tempest is to be pointed at an existing cloud but was not part of a
> deployment process. We want to run the tests for the supported
> services/extensions.

Thanks for clarifying, I heard some requests for the above "2" use case
and the autodiscovery would be nice for it.

> We should modularize the code around discovery so that the discovery
> functions return the changes to conf that would have to be made. The
> callers can then decide how that information is to be used. This would
> support both use cases. I have some changes to the verify_tempest_config
> code that does this which I will push up if the concept is agreed.

Great.

BTW, current API extension lists for Nova(api_extensions/ api_v3_extensions
in tempest.conf) don't work at all because tests with requires_ext() don't
exist in Nova API tests. I will add requires_ext() to Nova API tests, that
will be worth even if the autodiscovery is not implemented.


Thanks
Ken'ichi Ohmichi