<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 23, 2017 at 7:02 AM, Ken'ichi Ohmichi <span dir="ltr"><<a href="mailto:ken1ohmichi@gmail.com" target="_blank">ken1ohmichi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2017-03-22 14:32 GMT-07:00 Andrea Frittoli <<a href="mailto:andrea.frittoli@gmail.com">andrea.frittoli@gmail.com</a>>:<br>
><br>
><br>
> 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>
>><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 that.<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 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-<wbr>full-ubuntu-xenial - (existing job):<br>
>> > testing Cinder V3 API<br>
>> >   gate-tempest-dsvm-py35-ubuntu-<wbr>xenial - (existing job): testing Cinder<br>
>> > V3 API<br>
>> >   ...<br>
>> >   gate-tempest-dsvm-neutron-<wbr>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 microversions<br>
>> > or<br>
>> >   tempest/api/volume/  - All tests for V2 API and V3 API which<br>
>> > includes newer microversions<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">​+1, this looks better as no more version specific tests and all v2 tests should run as it is on v3 base version.​</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> ><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>
> One folder for everything means moving 4 or 5 modules only, so I think that<br>
> would<br>
> be a good option.<br>
><br>
> I would prefer to avoid though having a lot of v3 test classes that inherit<br>
> from<br>
> v2 test classes, and just set _api_version = 3.<br>
<br>
Yeah, I agree :-)<br></blockquote><div><br></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">​yea we should not have that.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">​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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">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. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">As you mentioned it can be same way we handle compute v2, v2.1 and + microversion tests. </div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">​.. 0 <a href="http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/cinder#n403">http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/cinder#n403</a> </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">Thanks</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;color:rgb(0,0,0)">gmann​</div><br></div></div>