<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 10, 2017 at 8:39 PM Ken'ichi Ohmichi <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi John,<br class="gmail_msg">
<br class="gmail_msg">
Now Tempest is testing microversions only for Nova and contains some<br class="gmail_msg">
testing framework for re-using for another projects.<br class="gmail_msg">
On this framework, we can implement necessary microversions tests as<br class="gmail_msg">
we want and actually many microversions of Nova are not tested by<br class="gmail_msg">
Tempest.<br class="gmail_msg">
We can see the tested microversion of Nova on<br class="gmail_msg">
<a href="https://github.com/openstack/tempest/blob/master/doc/source/microversion_testing.rst#microversion-tests-implemented-in-tempest" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/openstack/tempest/blob/master/doc/source/microversion_testing.rst#microversion-tests-implemented-in-tempest</a><br class="gmail_msg">
<br class="gmail_msg">
Before implementing microversion testing for Cinder, we will implement<br class="gmail_msg">
JSON-Schema validation for API responses for Cinder.<br class="gmail_msg">
The validation will be helpful for testing base microversion of Cinder<br class="gmail_msg">
API and we will be able to implement the microversion tests based on<br class="gmail_msg">
that.<br class="gmail_msg">
This implementation is marked as 7th priority in this Pike cycle as<br class="gmail_msg">
<a href="https://etherpad.openstack.org/p/pike-qa-priorities" rel="noreferrer" class="gmail_msg" target="_blank">https://etherpad.openstack.org/p/pike-qa-priorities</a><br class="gmail_msg">
<br class="gmail_msg">
In addition, now Cinder V3 API is not tested. So we are going to<br class="gmail_msg">
enable v3 tests with some restructure of Tempest in this cycle.<br class="gmail_msg">
The detail is described on the part of "Volume API" of<br class="gmail_msg">
<a href="https://etherpad.openstack.org/p/tempest-api-versions-in-pike" rel="noreferrer" class="gmail_msg" target="_blank">https://etherpad.openstack.org/p/tempest-api-versions-in-pike</a><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">
<br class="gmail_msg">
2017-03-10 11:37 GMT-08:00 John Griffith <<a href="mailto:john.griffith8@gmail.com" class="gmail_msg" target="_blank">john.griffith8@gmail.com</a>>:<br class="gmail_msg">
> Hey Everyone,<br class="gmail_msg">
><br class="gmail_msg">
> So along the lines of an earlier thread that went out regarding testing of<br class="gmail_msg">
> deprecated API's and Tempest etc [1].<br class="gmail_msg">
><br class="gmail_msg">
> Now that micro-versions are *the API versioning scheme to rule them all* one<br class="gmail_msg">
> question I've not been able to find an answer for is what we're going to<br class="gmail_msg">
> promise here for support and testing.  My understanding thus far is that the<br class="gmail_msg">
> "community" approach here is "nothing is ever deprecated, and everything is<br class="gmail_msg">
> supported forever".<br class="gmail_msg">
><br class="gmail_msg">
> That's sort of a tall order IMO, but ok.  I've already had some questions<br class="gmail_msg">
> from folks about implementing an explicit Tempest test for every<br class="gmail_msg">
> micro-versioned implementation of an API call also.  My response has been<br class="gmail_msg">
> "nahh, just always test latest available".  This kinda means that we're not<br class="gmail_msg">
> testing/supporting the previous versions as promised though.<br class="gmail_msg"></blockquote><div><br></div><div>We had a couple of sessions related to this topic at the PTG [0][1].</div><div><br></div><div>We agreed that we want to still maintain integration tests only in Tempest, which means that API micro versions that have no integration impact can be tested via functional tests.</div><div><br></div><div>Since we do schema validation, when someone wants to develop an integration tests for a specific micro version, there may be a gap in the schemas implemented on Tempest side and the current one - we had this case already in nova.</div><div>We decided we shall monitor this gap, and fill it with schema definition at least at the end of each cycle, or more often if required.</div><div><br></div><div>Tests can define which range or micro versions they are applicable to.</div><div>Initial tests for v3 in cinder will have no min_version, and they may get a max version if they're behaviour is not valid anymore beyond a certain microversion. Tests developed specifically for a micro versions will have min_version set accordingly.</div><div><br></div><div>In terms of which versions we test in the gate, for nova we always run with min_microversion = None and max_microversion = latest, which means that all tests will be executed.</div><div>Since micro versions are incremental, and each micro version usually involves no or one test on Tempest side, I think it will be a while before this becomes an issue for the common gate. </div><div><br></div><div>andrea</div><div><br></div><div>[0] <a href="https://etherpad.openstack.org/p/qa-ptg-pike-microversion">https://etherpad.openstack.org/p/qa-ptg-pike-microversion</a><br></div><div>[1] <a href="https://etherpad.openstack.org/p/qa-ptg-pike-schema-validation">https://etherpad.openstack.org/p/qa-ptg-pike-schema-validation</a> </div><div>[2] <a href="https://docs.openstack.org/developer/tempest/microversion_testing.html">https://docs.openstack.org/developer/tempest/microversion_testing.html</a>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br class="gmail_msg">
> Anyway; I'm certain that between Nova and the API-WG this has come up and is<br class="gmail_msg">
> probably addressed, just wondering if somebody can point me to some<br class="gmail_msg">
> documentation or policies in this respect.<br class="gmail_msg">
><br class="gmail_msg">
> Thanks,<br class="gmail_msg">
> John<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">
__________________________________________________________________________<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">
</blockquote></div></div>