2017-03-22 14:32 GMT-07:00 Andrea Frittoli <andrea.fritt...@gmail.com>: > > > On Wed, Mar 22, 2017 at 8:31 PM Sean McGinnis <sean.mcgin...@gmx.com> 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 >> > >> > 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 :-) > 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. > 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev