Open Stack

On Sat, 18 Jun 2016, Jamie Lennox wrote:

> Quick question: why do we need the service type or name in there? You
> really should know what API you're talking to already and it's just
> something that makes it more difficult to handle all the different APIs in
> a common way.

The basic idea is so that it is possible to write generic client code
that has a header with a specific name and purpose that can have a
value that works for multiple services and can be coded and talked
about in a generic way.

So in fact the reason the change is a good thing is exactly what you
say: The old way makes it more difficult to handle things in a common
way because you have to seek out lots of different headers. The library
referenced below lets you:

    version = microversion_parse.get_version(headers, service_type='compute')

and get back either the compute microversion, None or an error. Do it
again with 'identity' get back the identity microversion. Etc.

Another point: the old version of the header had "value" information on
both sides of the name value pair. The new version is more general.

Bonus for the lazy at heart (a virtue!): a client can send version
headers for every service being addressed in a suite of tasks in one
fell swoop.

And finally, we knew we needed to update the microversion headers to
get rid of two things which are deprecated:

* using 'X-' on headers
* referring to services by their project name when we should be using
   their service type

So if that change was going to be made anyway, and we wanted to avoid
having lots of miscellaneous headers (see proliferation guideline
below), may as well lump several changes to avoid too much churn and
have a tidy future.

Some potentially useful links:

* a library for parsing various microversion headers out of a variety of
   header representations:
   https://pypi.python.org/pypi/microversion_parse

* header non proliferation guideline:
   http://specs.openstack.org/openstack/api-wg/guidelines/headers.html#avoid-proliferating-headers

* adding support for the new style to nova:
   * the spec
   http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/modern-microversions.html
   * nova itself (as I think it was Ed has already pointed out)
   https://review.openstack.org/#/c/300077/
   * novaclient
   https://review.openstack.org/#/c/323362/

I hope some of that is useful.

-- 
Chris Dent               (╯°□°)╯︵┻━┻            http://anticdent.org/
freenode: cdent                                         tw: @anticdent