[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