Hi David, > -----Original Message----- > From: David Kranz [mailto:[email protected]] > 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
