[openstack-dev] [QA][Cinder]Removing Cinder v1 in Tempest

Ken'ichi Ohmichi ken1ohmichi at gmail.com
Tue Oct 11 02:23:20 UTC 2016


Thanks for pointing this up, Jordan

Before removing volume v1 API tests, it is nice to make the v2 API the
default of Tempest scenario tests.
Now the v1 and v2 is set as True on the default in the
configuration[1], and the v1 API is used in the scenario like [2].
So it is better to switch using v2 API on the default.

Thanks
Ken Ohmichi

---

[1]: https://github.com/openstack/tempest/blob/master/tempest/config.py#L770
[2]: https://github.com/openstack/tempest/blob/master/tempest/scenario/manager.py#L83


2016-10-10 11:37 GMT-07:00 Matt Riedemann <mriedem at linux.vnet.ibm.com>:
> On 10/10/2016 7:47 AM, Duncan Thomas wrote:
>>
>> If we can get them running on cinder patches via a different job, then
>> removing them from the common job afterwards seems reasonable.
>>
>> There's no strong will to remove them, several libraries still use them,
>> and given we're now supporting /all/ other API versions indefinitely,
>> keeping them around isn't that much of a burden.
>>
>> On 10 October 2016 at 15:32, Jordan Pittier <jordan.pittier at scality.com
>> <mailto:jordan.pittier at scality.com>> wrote:
>>
>>     Hi,
>>     I'd like to reduce the duration of a full Tempest run and I noticed
>>     that Cinder tests take a good amount of time (cumulative
>>     time 2149sec vs 2256sec for Nova, source code [0])
>>
>>     So I'd like to not run the Cinder v1 tests anymore, at least on the
>>     master branches.
>>
>>     I remember that Cinder  v1 is deprecated (it has been for what, 2
>>     years ?) Is the removal scheduled ? I don't see/feel a lot of
>>     efforts toward that removal but I may be missing something. Any way,
>>     that's not really my business but it's not really fair to all the
>>     projects that run the "common jobs" that Cinder "slows" everyone down.
>>
>>     What do you think ?
>>
>>     [0]
>>     :
>> https://github.com/JordanP/openstack-snippets/blob/master/tempest-timing/tempest_timing.py
>>
>> <https://github.com/JordanP/openstack-snippets/blob/master/tempest-timing/tempest_timing.py>
>>
>>
>> <https://www.scality.com/backup/?utm_source=signatures&utm_medium=email&utm_campaign=backup2016>
>>
>> __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> --
>> --
>> Duncan Thomas
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> So make it conditional in Tempest via a config option, disable volume v1
> tests by default for the integrated gate, and then add a new job that runs
> only on cinder changes (and maybe only in the experimental queue) that
> enables volume v1 tests. You could run it on cinder in the check/gate and
> skip the job from running unless something in the v1 API path is changed,
> there are examples of that in project-config.
>
> Nova used to have the v2 API in tree and this was kind of the eventual path
> to phasing out the Tempest testing on that code and got us to the point of
> removing the v2 *code*.  The compute v2 API itself is still honored via the
> v2.1 base microversion.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list