[openstack-dev] [api][nova][ironic] Microversion API HTTP header

Dmitry Tantsur dtantsur at redhat.com
Tue Jun 16 06:57:27 UTC 2015


On 06/15/2015 10:31 PM, Jay Pipes wrote:
>
>
> On 06/15/2015 02:09 PM, Dmitry Tantsur wrote:
>>
>>
>> 2015-06-15 19:50 GMT+02:00 Clint Byrum <clint at fewbar.com
>> <mailto:clint at fewbar.com>>:
>>
>>     Excerpts from Jay Pipes's message of 2015-06-15 10:07:39 -0700:
>>     > It has come to my attention in [1] that the microversion spec
>> for Nova
>>     > [2] and Ironic [3] have used the project name -- i.e. Nova and
>> Ironic --
>>     > instead of the name of the API -- i.e. "OpenStack Compute" and
>>     > "OpenStack Bare Metal" -- in the HTTP header that a client
>> passes to
>>     > indicate a preference for or knowledge of a particular API
>> microversion.
>>     >
>>     > The original spec said that the HTTP header should contain the
>> name of
>>     > the service type returned by the Keystone service catalog (which
>> is also
>>     > the official name of the REST API). I don't understand why the
>> spec was
>>     > changed retroactively and why Nova has been changed to return
>>     > X-OpenStack-Nova-API-Version instead of
>> X-OpenStack-Compute-API-Version
>>     > HTTP headers [4].
>>     >
>>     > To be blunt, Nova is the *implementation* of the OpenStack
>> Compute API.
>>     > Ironic is the *implementation* of the OpenStack BareMetal API.
>>     >
>>     > The HTTP headers should never have been changed like this, IMHO,
>> and I'm
>>     > disappointed that they were. In fact, it looks like a very
>> select group
>>     > of individuals pushed through this change [5] with little to no
>> input
>>     > from the mailing list or community.
>>     >
>>     > Since no support for these headers has yet to land in the client
>>     > packages, can we please reconsider this?
>>
>>     I tend to agree with you.
>>
>>     The juxtaposition is somewhat surprising. [1] Is cited as the
>> reason for
>>     making the change, but that governance change is addressing the
>> way we
>>     govern projects, not API's. The goal of the change itself is to
>>     encourage
>>     competition amongst projects. However, publishing an OpenStack API
>> with
>>     a project name anywhere in it is the opposite: it discourages
>>     alternative
>>     implementations. If we really believe there are no sacred cows and a
>>     nova
>>     replacement (or proxy, or accelerator, or or or..) could happen
>>     inside the
>>     OpenStack community, then we should be more careful about defining
>>     the API
>>
>>
>> If Ironic will still be the main authority to define "the baremetal
>> API", header renaming won't help the alternative implementations.
>
> IMHO, we need to start thinking of the public, versioned REST APIs as
> separate from both the implementation as well as the contributor
> community that develops the implementation.
>
> Assuming the implementation == the REST API promotes the attitude that
> it doesn't really matter what the REST API looks like or how it evolves,
> since "the code is the documentation" and "the code is the API". This
> does a disservice to the user of the REST API, IMO.
>
>> Also, what to use for services, that do not have direct program mapping?
>> I.e., I'm planning to add microversioning to ironic-inspector. Who is
>> going to define a proper service name? Myself? The ironic team? Should I
>> bother the TC?
>
> Does the ironic-inspector expose a REST API?

Yeah, that's why I'm asking :) Only 2 simple endpoints, but still.

>
> -jay
>
>>     However, if we do believe that Nova and Ironic are special, then
>> the API
>>     can stand as-is, though I still find it sub-optimal.
>>
>>     I'm a little bit worried that we don't have a guiding principle to
>> point
>>     at somewhere. Perhaps the API WG can encode guidance either way
>> ("We use
>>     project names", or "we use service types").
>>
>>     [1] https://review.openstack.org/#/c/145740/
>>
>>      >
>>      > Thanks,
>>      > -jay
>>      >
>>      > [1] https://review.openstack.org/#/c/187112/
>>      > [2]
>>      >
>>
>> https://github.com/openstack/nova-specs/blob/master/specs/kilo/implemented/api-microversions.rst
>>
>>      > [3]
>>      >
>>
>> https://github.com/openstack/ironic-specs/blob/master/specs/kilo/api-microversions.rst
>>
>>      > [4] https://review.openstack.org/#/c/155611/
>>      > [5] https://review.openstack.org/#/c/153183/
>>      >
>>
>>
>> __________________________________________________________________________
>>
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>
>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> --
>> -- Dmitry Tantsur
>> --
>>
>>
>> __________________________________________________________________________
>>
>> 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
>>
>
> __________________________________________________________________________
> 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




More information about the OpenStack-dev mailing list