[openstack-dev] [api][qa][tc][glance][keystone][cinder] Testing of deprecated API versions

Lance Bragstad lbragstad at gmail.com
Thu Mar 9 22:23:27 UTC 2017


On Thu, Mar 9, 2017 at 3:46 PM, Doug Hellmann <doug at 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].


[0] https://github.com/openstack/defcore/blob/master/2017.01.json
[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-March/113166.html



> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170309/c9a257bd/attachment.html>


More information about the OpenStack-dev mailing list