2017-03-22 19:31 GMT-07:00 <[email protected]>: > To have only one folder (tempest/api/volume/ ) looks really good, and, do we > plan to deem "api_version" and "microversion" as one thing? > > i.e., we will use the mechanism of microversion to skip v3 new functional > tests when the environment only supports v2?
Yeah, that is right. Tempest has the range of microversions with the config options min/max_microversions and we can select the target microversions. If both min_microversion and max_microversion are not specified(means None), microversion tests run as the help message[1]. So the configuration would be like gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job): testing Cinder V3 API catalog_type: Specify Cinder V3 API's one min_microversion: Don't specify max_microversion: Specify max microversion of the branch (master, stable) gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job): testing Cinder V2 API catalog_type: Specify Cinder V2 API's one min_microversion: Don't specify max_microversion: Don't specify Thanks --- [1]: https://github.com/openstack/tempest/blob/master/tempest/config.py#L776 > On Thu, Mar 23, 2017 at 7:02 AM, Ken'ichi Ohmichi ＜[email protected]＞ > wrote: >> >> 2017-03-22 14:32 GMT-07:00 Andrea Frittoli ＜[email protected]＞: >> ＞ >> ＞ >> ＞ On Wed, Mar 22, 2017 at 8:31 PM Sean McGinnis ＜[email protected]＞ >> wrote: >> ＞＞ >> ＞＞ On Wed, Mar 22, 2017 at 01:08:23PM -0700, Ken'ichi Ohmichi wrote: >> ＞＞ ＞ Hi, >> ＞＞ ＞ >> ＞＞ ＞ Now we need to update Tempest for following Cinder API status.. >> ＞＞ ＞ I have an idea for restructuring and happy to see feedback about >> that. >> >> ＞＞ ＞ >> ＞＞ ＞ Now Cinder API status is >> ＞＞ ＞ V1: Deprecated >> ＞＞ ＞ V2: Deprecated >> ＞＞ ＞ V3: Current >> ＞＞ ＞ V1 API tests have been removed from Tempest side already, so we just >> ＞＞ ＞ need to concentrate on V2 and V3 now. >> ＞＞ >> ＞＞ ＞ >> ＞＞ ＞ **Gate jobs** >> ＞＞ ＞ Most Cinder tests are implemented for V2 API on Tempest side and the >> ＞＞ ＞ base microversion of V3 is the same as V2. >> ＞＞ ＞ Then we can re-use V2 API tests for the base microversion of V3 API. >> ＞＞ ＞ One idea is that we can have Cinder V3 API tests as the default on >> the >> ＞＞ ＞ gate jobs and the V2 API tests as another job like the following >> ＞＞ ＞ because the V2 API is deprecated. >> ＞＞ ＞ >> ＞＞ ＞ gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job): >> ＞＞ ＞ testing Cinder V3 API >> ＞＞ ＞ gate-tempest-dsvm-py35-ubuntu-xenial - (existing job): testing >> Cinder >> ＞＞ ＞ V3 API >> ＞＞ ＞ ... >> ＞＞ ＞ gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job): >> ＞＞ ＞ testing Cinder V2 API >> ＞＞ ＞ >> ＞＞ >> ＞ I guess this job would run against tempest and cinder only? >> >> A nice point, I think so. >> >> ＞＞ +1 I like this idea. >> ＞＞ >> ＞＞ ＞ We had the same testing way for Nova V2 API and V2.1 API before, and >> ＞＞ ＞ we could avoid copy&paste V2 test code for V2.1 API on Tempest. >> ＞＞ ＞ >> ＞＞ ＞ **Test Structure** >> ＞＞ ＞ Current test structure is like: >> ＞＞ ＞ tempest/api/volume/ - V2 API tests >> ＞＞ ＞ tempest/api/volume/v2 - V2 API tests >> ＞＞ ＞ tempest/api/volume/v3 - V3 API tests >> ＞＞ ＞ Yes, this is mess. >> ＞＞ ＞ For re-using V2 API tests for V3 API, it would be better to remove >> ＞＞ ＞ "v2" from V2 API tests for avoiding confusions. >> ＞＞ ＞ >> ＞＞ ＞ A new structure could be >> ＞＞ ＞ tempest/api/volume/ - All tests for V2 API and the base >> ＞＞ ＞ microversion of V3 API >> ＞＞ ＞ tempest/api/volume/v3 - V3 API specific tests for newer >> microversions >> ＞＞ ＞ or >> ＞＞ ＞ tempest/api/volume/ - All tests for V2 API and V3 API which >> ＞＞ ＞ includes newer microversions > > > +1, this looks better as no more version specific tests and all v2 tests > should run as it is on v3 base version. > > >> >> ＞＞ ＞ >> ＞＞ ＞ As the reference, Nova API structure is like the later. >> ＞＞ >> ＞＞ I like the last one better as well. >> ＞＞ >> ＞ My favourite option would be that that generates less churn in the code >> :) >> ＞ One folder for everything means moving 4 or 5 modules only, so I think >> that >> ＞ would >> ＞ be a good option. >> ＞ >> ＞ I would prefer to avoid though having a lot of v3 test classes that >> inherit >> ＞ from >> ＞ v2 test classes, and just set _api_version = 3. >> >> Yeah, I agree :-) > > > > yea we should not have that. > > >> >> >> ＞ As long as we can assume we will never run v2 and v3 in the same job, we >> ＞ could >> ＞ have cinder_api_version as a configuration setting, to determine which >> ＞ cinder >> ＞ endpoint to hit when running the volume tests. >> >> Or it would be enough to have the existing "catalog_type", >> "min_microversion" and "max_microversion" only without api_v1/v2/v3 to >> control the target API version, because of the above separated gate >> jobs. >> > > Yes, so devstack does set different catalog for v2 and v3 [0]. Based on > those catalog_type configured on tempest config(we already have that for > volume API config) auth can select the right endpoints to make the API call. > > All existing tests can be run for both API without any extra class or > change. This way we can get rid of 'api_version' in all volumes clients and > have them as single copy for v2 and v3 base. > Further v3 microversion tests can be implemented as accordingly by sending > the microversion header on API request. and devstack can tell Temepst not to > set microversion if catalog_type volume_v2 is being asked to run the tests. > > As you mentioned it can be same way we handle compute v2, v2.1 and + > microversion tests. > > >> >> ＞ Apart from the volume tests, if we split the gate jobs into standard one >> ＞ running v3 >> ＞ plus and extra v2 one, we should make sure that all tests that use the >> ＞ volume API >> ＞ use a consistent version of the volume API. Nova as well should be >> ＞ configured if >> ＞ possible to use the same volume API version. >> >> This also is a nice point. >> Nova team also has a plan to use cinder v3 as the default in Pike. >> We have consistent direction now. >> >> Thanks >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > .. 0 > http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/cinder#n403 > > Thanks > gmann > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
