[openstack-dev] Version header for OpenStack microversion support

Monty Taylor mordred at inaugust.com
Tue Jun 21 14:47:23 UTC 2016

On 06/21/2016 12:59 AM, Clint Byrum wrote:
> Excerpts from Edward Leafe's message of 2016-06-20 20:41:56 -0500:
>> On Jun 18, 2016, at 9:03 AM, Clint Byrum <clint at fewbar.com> wrote:
>>> Whatever API version is used behind the compute API is none of the user's
>>> business.
>> Actually, yeah, it is.
>> If I write an app or a tool that expects to send information in a certain format, and receive responses in a certain format, I don't want that to change when the cloud operator upgrades their system. I only want things to change when I specifically request that they change by specifying a new microversion.
> The things I get back in the compute API are the purview of the compute
> API, and nothing else.
> Before we go too far down this road, is there actually an example of
> one API providing a proxy to another directly? If so, is it something
> we think is actually a good idea?
> Because otherwise, the API I'm talking to needs to be clear about what
> it does and does not emit and/or accept. That contract would just be
> the microversion of the API I'm talking to.

I'll agree with Clint here, and give an example.

When I talk to Nova and get a detail record for a server, Nova talks to
Neutron and puts data that it receives into the addresses dict on the
server record. This is not the neutron data structure. In fact, it has
some information from the Network and some from the Port (it would be
helpful if it had _more_ info, but that's not the point here)

In any case, the data structure returned by Nova is not related in any
way to the version of Neutron that nova is talking to - nor should it be.

Here's an example (in yaml not json)

    - OS-EXT-IPS-MAC:mac_addr: fa:16:3e:ea:d8:0d
      OS-EXT-IPS:type: fixed
      version: 4

If you want a neutron record, you'll talk to neutron.

More information about the OpenStack-dev mailing list