Excerpts from Ghanshyam Mann's message of 2017-03-10 10:55:25 +0900: > On Fri, Mar 10, 2017 at 7:23 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > > > > > > > On Thu, Mar 9, 2017 at 3:46 PM, Doug Hellmann <d...@doughellmann.com> > > wrote: > > > >> Excerpts from Andrea Frittoli's message of 2017-03-09 20:53:54 +0000: > >> > Hi folks, > >> > > >> > I'm trying to figure out what's the best approach to fade out testing of > >> > deprecated API versions. > >> > We currently host in Tempest API tests for Glance API v1, Keystone API > >> v2 > >> > and Cinder API v1. > >> > > >> > According to the guidelines for the "follow-standard-deprecation" tag > >> [0], > >> > when projects that have that tag deprecate a feature: > >> > > >> > "Code will be frozen and only receive minimal maintenance (just so that > >> it > >> > continues to work as-is)." > >> > > >> > I interpret this so that projects should maintain some level of testing > >> of > >> > the deprecated feature, including a deprecated API version. > >> > The QA team does not see value in testing deprecated API versions in the > >> > common gate jobs, so my question is what do to with those tests. > >> > > >> > One option is to maintain them in Tempest until the API version is > >> removed, > >> > and run them in dedicated project jobs. > >> > This means that tempest would have to run those jobs as well, so three > >> > extra jobs, until the API version is removed. > >> > > >> > The other option is to move those tests out of Tempest, into the > >> projects. > >> > This would imply back porting them to all relevant branches as well, > >> but it > >> > would have the advantage of decoupling them from Tempest. It should be > >> no > >> > concern from an API stability POV since the code for that API will be > >> > frozen. > >> > Tests for deprecated APIs in cinder, keystone and glance are all - as > >> far > >> > as I can tell - removed or deprecated from interoperability guidelines, > >> so > >> > moving the tests out of Tempest would not be an issue in that sense. > >> > > >> > The 2nd option involves a bit more initial overhead for the removal of > >> > tests, but I think it would works for the best on the long term. > >> > > >> > There is a 3rd option as well, which is to stop running integration > >> testing > >> > on deprecated API versions before they are actually removed, but I feel > >> > that would not meet the criteria defined by the > >> follow-standard-deprecation > >> > tag. > >> > > >> > Thoughts? > >> > > >> > andrea > >> > >> Are any of those tests used by the interoperability working group > >> (formerly DefCore)? > >> > >> > > 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]. > > > > Yes, it seems no Volume v1 and Keystone v2 tests usage in defcore > 2017.01.json [0]. But there are some compute tests which internally use > glance v1 API call [2]. But on mentioned flagged action- Nova already moved > to v2 APIs and tempest part is pending which can be fixed to make call on > v2 APIs only (which can be part of this work and quick). > > From options about deprecated APIs testing, I am with options 2 which > really take out the load of Tempest tests maintenance and gate. > > But another question is about stable branch testing of those API, like > glance v1 and identity v2 APIs are supported (not deprecated) in Mitaka. > As Tempest is responsible of testing all stable branch behavior too, Should > we keep testing them till all Mitaka EOL (till APIs are in deprecated > state in all stable branch) ?
Excellent point. Doug > > > > > [0] https://github.com/openstack/defcore/blob/master/2017.01.json > > [1] http://lists.openstack.org/pipermail/openstack-dev/ > > 2017-March/113166.html > > > > [2] > https://git.openstack.org/cgit/openstack/defcore/tree/2017.01.json#n294 > > > > > > >> Doug > >> > >> > > >> > [0] > >> > https://governance.openstack.org/tc/reference/tags/assert_fo > >> llows-standard-deprecation.html > >> > >> ____________________________________________________________ > >> ______________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib > >> e > >> 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 > > > > __________________________________________________________________________ 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
