Hi John, Now Tempest is testing microversions only for Nova and contains some testing framework for re-using for another projects. On this framework, we can implement necessary microversions tests as we want and actually many microversions of Nova are not tested by Tempest. We can see the tested microversion of Nova on https://github.com/openstack/tempest/blob/master/doc/source/microversion_testing.rst#microversion-tests-implemented-in-tempest
Before implementing microversion testing for Cinder, we will implement JSON-Schema validation for API responses for Cinder. The validation will be helpful for testing base microversion of Cinder API and we will be able to implement the microversion tests based on that. This implementation is marked as 7th priority in this Pike cycle as https://etherpad.openstack.org/p/pike-qa-priorities In addition, now Cinder V3 API is not tested. So we are going to enable v3 tests with some restructure of Tempest in this cycle. The detail is described on the part of "Volume API" of https://etherpad.openstack.org/p/tempest-api-versions-in-pike Thanks Ken Ohmichi --- 2017-03-10 11:37 GMT-08:00 John Griffith <john.griffi...@gmail.com>: > Hey Everyone, > > So along the lines of an earlier thread that went out regarding testing of > deprecated API's and Tempest etc [1]. > > Now that micro-versions are *the API versioning scheme to rule them all* one > question I've not been able to find an answer for is what we're going to > promise here for support and testing. My understanding thus far is that the > "community" approach here is "nothing is ever deprecated, and everything is > supported forever". > > That's sort of a tall order IMO, but ok. I've already had some questions > from folks about implementing an explicit Tempest test for every > micro-versioned implementation of an API call also. My response has been > "nahh, just always test latest available". This kinda means that we're not > testing/supporting the previous versions as promised though. > > Anyway; I'm certain that between Nova and the API-WG this has come up and is > probably addressed, just wondering if somebody can point me to some > documentation or policies in this respect. > > Thanks, > John > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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