<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 22, 2017 at 8:31 PM Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Mar 22, 2017 at 01:08:23PM -0700, Ken'ichi Ohmichi wrote:<br class="gmail_msg">
> Hi,<br class="gmail_msg">
><br class="gmail_msg">
> Now we need to update Tempest for following Cinder API status.<br class="gmail_msg">
> I have an idea for restructuring and happy to see feedback about that.<br class="gmail_msg">
><br class="gmail_msg">
> Now Cinder API status is<br class="gmail_msg">
>   V1: Deprecated<br class="gmail_msg">
>   V2: Deprecated<br class="gmail_msg">
>   V3: Current<br class="gmail_msg">
> V1 API tests have been removed from Tempest side already, so we just<br class="gmail_msg">
> need to concentrate on V2 and V3 now. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br class="gmail_msg">
> **Gate jobs**<br class="gmail_msg">
> Most Cinder tests are implemented for V2 API on Tempest side and the<br class="gmail_msg">
> base microversion of V3 is the same as V2.<br class="gmail_msg">
> Then we can re-use V2 API tests for the base microversion of V3 API.<br class="gmail_msg">
> One idea is that we can have Cinder V3 API tests as the default on the<br class="gmail_msg">
> gate jobs and the V2 API tests as another job like the following<br class="gmail_msg">
> because the V2 API is deprecated.<br class="gmail_msg">
><br class="gmail_msg">
>   gate-tempest-dsvm-neutron-full-ubuntu-xenial - (existing job):<br class="gmail_msg">
> testing Cinder V3 API<br class="gmail_msg">
>   gate-tempest-dsvm-py35-ubuntu-xenial - (existing job): testing Cinder V3 API<br class="gmail_msg">
>   ...<br class="gmail_msg">
>   gate-tempest-dsvm-neutron-full-ubuntu-xenial-cinder-v2: (new job):<br class="gmail_msg">
> testing Cinder V2 API<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>I guess this job would run against tempest and cinder only?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+1 I like this idea.<br class="gmail_msg">
<br class="gmail_msg">
> We had the same testing way for Nova V2 API and V2.1 API before, and<br class="gmail_msg">
> we could avoid copy&paste V2 test code for V2.1 API on Tempest.<br class="gmail_msg">
><br class="gmail_msg">
> **Test Structure**<br class="gmail_msg">
> Current test structure is like:<br class="gmail_msg">
>   tempest/api/volume/  - V2 API tests<br class="gmail_msg">
>   tempest/api/volume/v2 - V2 API tests<br class="gmail_msg">
>   tempest/api/volume/v3 - V3 API tests<br class="gmail_msg">
> Yes, this is mess.<br class="gmail_msg">
> For re-using V2 API tests for V3 API, it would be better to remove<br class="gmail_msg">
> "v2" from V2 API tests for avoiding confusions.<br class="gmail_msg">
><br class="gmail_msg">
> A new structure could be<br class="gmail_msg">
>   tempest/api/volume/  - All tests for V2 API and the base<br class="gmail_msg">
> microversion of V3 API<br class="gmail_msg">
>   tempest/api/volume/v3 - V3 API specific tests for newer microversions<br class="gmail_msg">
> or<br class="gmail_msg">
>   tempest/api/volume/  - All tests for V2 API and V3 API which<br class="gmail_msg">
> includes newer microversions<br class="gmail_msg">
><br class="gmail_msg">
> As the reference, Nova API structure is like the later.<br class="gmail_msg">
<br class="gmail_msg">
I like the last one better as well.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>My favourite option would be that that generates less churn in the code :)</div><div>One folder for everything means moving 4 or 5 modules only, so I think that would</div><div>be a good option.</div><div><br></div><div>I would prefer to avoid though having a lot of v3 test classes that inherit from</div><div>v2 test classes, and just set _api_version = 3.</div><div><br></div><div>As long as we can assume we will never run v2 and v3 in the same job, we could</div><div>have cinder_api_version as a configuration setting, to determine which cinder</div><div>endpoint to hit when running the volume tests.</div><div><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br class="gmail_msg">
> Any thoughts?<br class="gmail_msg">
><br class="gmail_msg">
> Thanks<br class="gmail_msg">
> Ken Ohmichi<br class="gmail_msg">
><br class="gmail_msg">
> __________________________________________________________________________<br class="gmail_msg">
> OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
<br class="gmail_msg">
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></blockquote><div><br></div><div>Apart from the volume tests, if we split the gate jobs into standard one running v3</div><div>plus and extra v2 one, we should make sure that all tests that use the volume API</div><div>use a consistent version of the volume API. Nova as well should be configured if</div><div>possible to use the same volume API version.</div><div><br></div><div>andrea </div></div></div>