<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 9, 2017 at 3:46 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.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">Excerpts from Andrea Frittoli's message of 2017-03-09 20:53:54 +0000:<br>
<div><div class="gmail-m_-7127463423234097919gmail-h5">> Hi folks,<br>
><br>
> I'm trying to figure out what's the best approach to fade out testing of<br>
> deprecated API versions.<br>
> We currently host in Tempest API tests for Glance API v1, Keystone API v2<br>
> and Cinder API v1.<br>
><br>
> According to the guidelines for the "follow-standard-deprecation" tag [0],<br>
> when projects that have that tag deprecate a feature:<br>
><br>
> "Code will be frozen and only receive minimal maintenance (just so that it<br>
> continues to work as-is)."<br>
><br>
> I interpret this so that projects should maintain some level of testing of<br>
> the deprecated feature, including a deprecated API version.<br>
> The QA team does not see value in testing deprecated API versions in the<br>
> common gate jobs, so my question is what do to with those tests.<br>
><br>
> One option is to maintain them in Tempest until the API version is removed,<br>
> and run them in dedicated project jobs.<br>
> This means that tempest would have to run those jobs as well, so three<br>
> extra jobs, until the API version is removed.<br>
><br>
> The other option is to move those tests out of Tempest, into the projects.<br>
> This would imply back porting them to all relevant branches as well, but it<br>
> would have the advantage of decoupling them from Tempest. It should be no<br>
> concern from an API stability POV since the code for that API will be<br>
> frozen.<br>
> Tests for deprecated APIs in cinder, keystone and glance are all - as far<br>
> as I can tell - removed or deprecated from interoperability guidelines, so<br>
> moving the tests out of Tempest would not be an issue in that sense.<br>
><br>
> The 2nd option involves a bit more initial overhead for the removal of<br>
> tests, but I think it would works for the best on the long term.<br>
><br>
> There is a 3rd option as well, which is to stop running integration testing<br>
> on deprecated API versions before they are actually removed, but I feel<br>
> that would not meet the criteria defined by the follow-standard-deprecation<br>
> tag.<br>
><br>
> Thoughts?<br>
><br>
> andrea<br>
<br>
</div></div>Are any of those tests used by the interoperability working group<br>
(formerly DefCore)?<br>
<br></blockquote><div><br></div><div>That's a good question. I was very curious about this because last I checked keystone had v2.0 calls required for defcore. Looks like that might not be the case anymore [0]? I started a similar thread to this after the PTG since that was something our group talked about extensively during the deprecation session [1].</div><div><br></div><div><br></div><div>[0] <a href="https://github.com/openstack/defcore/blob/master/2017.01.json" target="_blank">https://github.com/<wbr>openstack/defcore/blob/master/<wbr>2017.01.json</a></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-March/113166.html">http://lists.openstack.org/pipermail/openstack-dev/2017-March/113166.html</a></div><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">
Doug<br>
<br>
><br>
> [0]<br>
> <a href="https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html" rel="noreferrer" target="_blank">https://governance.openstack.o<wbr>rg/tc/reference/tags/assert_fo<wbr>llows-standard-deprecation.htm<wbr>l</a><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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div><br></div></div>