[openstack-dev] [api][nova][ironic] Microversion API HTTP header
Dmitry Tantsur
divius.inside at gmail.com
Mon Jun 15 18:09:17 UTC 2015
2015-06-15 19:50 GMT+02:00 Clint Byrum <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.
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?
>
> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
--
-- Dmitry Tantsur
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/3b9d02ef/attachment.html>
More information about the OpenStack-dev
mailing list