<div class="zcontentRow"> <p><span style="font-family: arial, helvetica, sans-serif;">The current mechanism of microversion looks a bit strange to me.<br></span></p><p><a href="https://github.com/openstack/tempest/blob/c0223906280619b6eb1ffb3fa200136fd3050528/tempest/api/volume/v3/base.py#L49-L52" _src="https://github.com/openstack/tempest/blob/c0223906280619b6eb1ffb3fa200136fd3050528/tempest/api/volume/v3/base.py#L49-L52" style="font-family: arial, helvetica, sans-serif; text-decoration: underline;"><span style="font-family: arial, helvetica, sans-serif;">https://github.com/openstack/tempest/blob/c0223906280619b6eb1ffb3fa200136fd3050528/tempest/api/volume/v3/base.py#L49-L52</span></a> </p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; min-height: 14px; font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; font-size: 17.5px; line-height: 25px; white-space: normal; outline: none !important; background-color: rgb(255, 255, 255);"><span style="font-family: arial, helvetica, sans-serif;">that means we set microversion at setUp and clear it at tearDown, but that is strange, </span></p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; min-height: 14px; font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; font-size: 17.5px; line-height: 25px; white-space: normal; outline: none !important; background-color: rgb(255, 255, 255);"><span style="font-family: arial, helvetica, sans-serif;">1) we never set microvertion at testcase level, i.e., we only set microversion at class level,  somethink like:</span></p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; min-height: 14px; font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; font-size: 17.5px; line-height: 25px; white-space: normal; outline: none !important; background-color: rgb(255, 255, 255);"><span style="font-family: arial, helvetica, sans-serif;">        class KeyPairsV210TestJSON(base.</span><wbr style="box-sizing: border-box; outline: none !important;"><span style="font-family: arial, helvetica, sans-serif;">BaseKeypairTest):</span></p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; min-height: 14px; font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; font-size: 17.5px; line-height: 25px; white-space: normal; outline: none !important; background-color: rgb(255, 255, 255);"><span style="font-family: arial, helvetica, sans-serif;">            min_microversion = '2.10'<br style="box-sizing: border-box; outline: none !important;"></span></p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; min-height: 14px; font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; font-size: 17.5px; line-height: 25px; white-space: normal; outline: none !important; background-color: rgb(255, 255, 255);"><span style="font-family: arial, helvetica, sans-serif;">2) if microversion is set to None in tearDown, then in resource_cleanup the client will not have the correct microversion to work.</span></p><p><span style="font-family: arial, helvetica, sans-serif;">to sum up, why we will set and clear microversion at testcase level while not at testclass level<span style="font-family: Arial, 宋体, 'Microsoft Yahei', 'Lucida Grande', Verdana, Lucida, Helvetica, sans-serif; font-size: 17.5px; line-height: 25px; background-color: rgb(255, 255, 255);">?</span></span><br></p><p><br></p><p><br></p><div><div class="zhistoryRow" style="display:block"><div class="zhistoryDes" style="width: 100%; height: 28px; line-height: 28px; background-color: #E0E5E9; color: #1388FF; text-align: center;" language-data="HistoryOrgTxt">Original Mail</div><div id="zwriteHistoryContainer"><div class="control-group zhistoryPanel"><div class="zhistoryHeader" style="padding: 8px; background-color: #F5F6F8;"><div><strong language-data="HistorySenderTxt">Sender: </strong><span class="zreadUserName"> ＜ken1ohmichi@gmail.com＞;</span></div><div><strong language-data="HistoryTOTxt">To: </strong><span class="zreadUserName" style="display: inline-block;"> ＜openstack-dev@lists.openstack.org＞;</span></div><div><strong language-data="HistoryDateTxt">Date: </strong><span class="">2017/03/23 11:24</span></div><div><strong language-data="HistorySubjectTxt">Subject: </strong><span class="zreadTitle"><strong>Re: [openstack-dev] [qa][cinder] RFC: Cinder test on Tempest</strong></span></div></div><p class="zhistoryContent"><br></p><div>2017-03-22 19:31 GMT-07:00  ＜zhu.fanglei@zte.com.cn＞:<br>＞ To have only one folder (tempest/api/volume/ ) looks really good, and, do we<br>＞ plan to deem "api_version" and "microversion" as one thing?<br>＞<br>＞ i.e., we will use the mechanism of microversion to skip v3 new functional<br>＞ tests when the environment only supports v2?<br><br>Yeah, that is right.<br>Tempest has the range of microversions with the config options<br>min/max_microversions and we can select the target  microversions.<br>If both min_microversion and max_microversion are not specified(means<br>None), microversion tests run as the help message[1].<br><br>So the configuration would be like<br><br>gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job): testing<br>Cinder V3 API<br>  catalog_type: Specify Cinder V3 API's one<br>  min_microversion: Don't specify<br>  max_microversion: Specify max microversion of the branch (master, stable)<br><br>gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):<br>testing Cinder V2 API<br>  catalog_type: Specify Cinder V2 API's one<br>  min_microversion: Don't specify<br>  max_microversion: Don't specify<br><br>Thanks<br><br>---<br>[1]: https://github.com/openstack/tempest/blob/master/tempest/config.py#L776<br><br><br>＞ On Thu, Mar 23, 2017 at 7:02 AM, Ken'ichi Ohmichi ＜ken1ohmichi@gmail.com＞<br>＞ wrote:<br>＞＞<br>＞＞ 2017-03-22 14:32 GMT-07:00 Andrea Frittoli ＜andrea.frittoli@gmail.com＞:<br>＞＞ ＞<br>＞＞ ＞<br>＞＞ ＞ On Wed, Mar 22, 2017 at 8:31 PM Sean McGinnis ＜sean.mcginnis@gmx.com＞<br>＞＞ wrote:<br>＞＞ ＞＞<br>＞＞ ＞＞ On Wed, Mar 22, 2017 at 01:08:23PM -0700, Ken'ichi Ohmichi wrote:<br>＞＞ ＞＞ ＞ Hi,<br>＞＞ ＞＞ ＞<br>＞＞ ＞＞ ＞ Now we need to update Tempest for following Cinder API status..<br>＞＞ ＞＞ ＞ I have an idea for restructuring and happy to see feedback about<br>＞＞ that.<br>＞＞<br>＞＞ ＞＞ ＞<br>＞＞ ＞＞ ＞ Now Cinder API status is<br>＞＞ ＞＞ ＞   V1: Deprecated<br>＞＞ ＞＞ ＞   V2: Deprecated<br>＞＞ ＞＞ ＞   V3: Current<br>＞＞ ＞＞ ＞ V1 API tests have been removed from Tempest side already, so we just<br>＞＞ ＞＞ ＞ need to concentrate on V2 and V3 now.<br>＞＞ ＞＞<br>＞＞ ＞＞ ＞<br>＞＞ ＞＞ ＞ **Gate jobs**<br>＞＞ ＞＞ ＞ Most Cinder tests are implemented for V2 API on Tempest side and the<br>＞＞ ＞＞ ＞ base microversion of V3 is the same as V2.<br>＞＞ ＞＞ ＞ Then we can re-use V2 API tests for the base microversion of V3 API.<br>＞＞ ＞＞ ＞ One idea is that we can have Cinder V3 API tests as the default on<br>＞＞ the<br>＞＞ ＞＞ ＞ gate jobs and the V2 API tests as another job like the following<br>＞＞ ＞＞ ＞ because the V2 API is deprecated.<br>＞＞ ＞＞ ＞<br>＞＞ ＞＞ ＞   gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job):<br>＞＞ ＞＞ ＞ testing Cinder V3 API<br>＞＞ ＞＞ ＞   gate-tempest-dsvm-py35-ubuntu-xenial - (existing job): testing<br>＞＞ Cinder<br>＞＞ ＞＞ ＞ V3 API<br>＞＞ ＞＞ ＞   ...<br>＞＞ ＞＞ ＞   gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):<br>＞＞ ＞＞ ＞ testing Cinder V2 API<br>＞＞ ＞＞ ＞<br>＞＞ ＞＞<br>＞＞ ＞ I guess this job would run against tempest and cinder only?<br>＞＞<br>＞＞ A nice point, I think so.<br>＞＞<br>＞＞ ＞＞ +1 I like this idea.<br>＞＞ ＞＞<br>＞＞ ＞＞ ＞ We had the same testing way for Nova V2 API and V2.1 API before, and<br>＞＞ ＞＞ ＞ we could avoid copy&paste V2 test code for V2.1 API on Tempest.<br>＞＞ ＞＞ ＞<br>＞＞ ＞＞ ＞ **Test Structure**<br>＞＞ ＞＞ ＞ Current test structure is like:<br>＞＞ ＞＞ ＞   tempest/api/volume/  - V2 API tests<br>＞＞ ＞＞ ＞   tempest/api/volume/v2 - V2 API tests<br>＞＞ ＞＞ ＞   tempest/api/volume/v3 - V3 API tests<br>＞＞ ＞＞ ＞ Yes, this is mess.<br>＞＞ ＞＞ ＞ For re-using V2 API tests for V3 API, it would be better to remove<br>＞＞ ＞＞ ＞ "v2" from V2 API tests for avoiding confusions.<br>＞＞ ＞＞ ＞<br>＞＞ ＞＞ ＞ A new structure could be<br>＞＞ ＞＞ ＞   tempest/api/volume/  - All tests for V2 API and the base<br>＞＞ ＞＞ ＞ microversion of V3 API<br>＞＞ ＞＞ ＞   tempest/api/volume/v3 - V3 API specific tests for newer<br>＞＞ microversions<br>＞＞ ＞＞ ＞ or<br>＞＞ ＞＞ ＞   tempest/api/volume/  - All tests for V2 API and V3 API which<br>＞＞ ＞＞ ＞ includes newer microversions<br>＞<br>＞<br>＞ +1, this looks better as no more version specific tests and all v2 tests<br>＞ should run as it is on v3 base version.<br>＞<br>＞<br>＞＞<br>＞＞ ＞＞ ＞<br>＞＞ ＞＞ ＞ As the reference, Nova API structure is like the later.<br>＞＞ ＞＞<br>＞＞ ＞＞ I like the last one better as well.<br>＞＞ ＞＞<br>＞＞ ＞ My favourite option would be that that generates less churn in the code<br>＞＞ :)<br>＞＞ ＞ One folder for everything means moving 4 or 5 modules only, so I think<br>＞＞ that<br>＞＞ ＞ would<br>＞＞ ＞ be a good option.<br>＞＞ ＞<br>＞＞ ＞ I would prefer to avoid though having a lot of v3 test classes that<br>＞＞ inherit<br>＞＞ ＞ from<br>＞＞ ＞ v2 test classes, and just set _api_version = 3.<br>＞＞<br>＞＞ Yeah, I agree :-)<br>＞<br>＞<br>＞<br>＞ yea we should not have that.<br>＞<br>＞<br>＞＞<br>＞＞<br>＞＞ ＞ As long as we can assume we will never run v2 and v3 in the same job, we<br>＞＞ ＞ could<br>＞＞ ＞ have cinder_api_version as a configuration setting, to determine which<br>＞＞ ＞ cinder<br>＞＞ ＞ endpoint to hit when running the volume tests.<br>＞＞<br>＞＞ Or it would be enough to have the existing "catalog_type",<br>＞＞ "min_microversion" and "max_microversion" only without api_v1/v2/v3 to<br>＞＞ control the target API version, because of the above separated gate<br>＞＞ jobs.<br>＞＞<br>＞<br>＞ Yes, so devstack does set different catalog for v2 and v3 [0]. Based on<br>＞ those catalog_type configured on tempest config(we already have that for<br>＞ volume API config) auth can select the right endpoints to make the API call.<br>＞<br>＞ All existing tests can be run for both API without any extra class or<br>＞ change. This way we can get rid of 'api_version' in all volumes clients and<br>＞ have them as single copy for v2 and v3 base.<br>＞ Further v3 microversion tests can be implemented as accordingly by sending<br>＞ the microversion header on API request. and devstack can tell Temepst not to<br>＞ set microversion if catalog_type volume_v2 is being asked to run the tests.<br>＞<br>＞ As you mentioned it can be same way we handle compute v2, v2.1 and +<br>＞ microversion tests.<br>＞<br>＞<br>＞＞<br>＞＞ ＞ Apart from the volume tests, if we split the gate jobs into standard one<br>＞＞ ＞ running v3<br>＞＞ ＞ plus and extra v2 one, we should make sure that all tests that use the<br>＞＞ ＞ volume API<br>＞＞ ＞ use a consistent version of the volume API. Nova as well should be<br>＞＞ ＞ configured if<br>＞＞ ＞ possible to use the same volume API version.<br>＞＞<br>＞＞ This also is a nice point.<br>＞＞ Nova team also has a plan to use cinder v3 as the default in Pike.<br>＞＞ We have consistent direction now.<br>＞＞<br>＞＞ Thanks<br>＞＞<br>＞＞ __________________________________________________________________________<br>＞＞ OpenStack Development Mailing List (not for usage questions)<br>＞＞ Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>＞＞ http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>＞<br>＞<br>＞<br>＞ .. 0<br>＞ http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/cinder#n403<br>＞<br>＞ Thanks<br>＞ gmann<br>＞<br>＞<br>＞<br>＞<br>＞ __________________________________________________________________________<br>＞ OpenStack Development Mailing List (not for usage questions)<br>＞ Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>＞ http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>＞<br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></div><p><br></p></div></div></div></div><p><br></p> </div>