Open Stack

On Wed, Apr 8, 2015 at 7:38 AM Chris Friesen <chris.friesen at windriver.com>
wrote:

> On 04/07/2015 11:35 PM, Michael Davies wrote:
> > I agree with Jim R's suggestion - it's really up to the consumer as to
> what they
> > want to do.  Having said that...
> >
> > I think that any consumer wants to use the latest version of the API
> that it can
> > support.
> >
> > And so since we're not planning on making any breaking API changes[1], I
> think
> > any consumer wants to:
> >
> > a) have a concept of the latest API version that it has been coded for
> > b) then, in negotiation with the server, choose a version that suffices:
> > b1) negotiated_version = min(your code's max version, max Ironic server
> version) and
> > b2) negotiated_version > your code's supported version
> > b3) negotiated_version > Ironic API's minimum version
>
> Is that statement about "not planning on making any breaking API changes"
> an
> intention or a guarantee?
>
> The reason I ask is that doc/source/devref/api_microversions.rst contains
> an
> explicit mention of making breaking changes:  "So breaking changes can be
> added
> to the API without breaking users who don't specifically ask for it."
>
>
We will continue to support the same API that we had at the point we
introduced microversioning, which can be represented as v1.1, and is
inferred when there is no version header in the request. This should be
completely compatible with any client built against stable/juno.

There was a change introduced during Kilo which may break some clients,
were they not to upgrade; that change is only exposed when the requested
version is >= 1.2. Thus, older clients are not affected (but also do not
see new features).

In versions 1.3 - 1.6, we made several additions that we believed would not
break any client expecting v1.2, but incremented the API microversion to
indicate those changes. In this way, a newer client could discover what is
supported by a server it connects to.

I have no plans to remove support for v1.1 at this time. The language in
the spec lays out the approach we should take, were we ever to find the
need to remove support for v1.1. While I hope we never need to, describing
it was an important part of the process to arrive at how we implemented
microversions.

-Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150408/718fb8ab/attachment.html>