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 <[email protected]
<mailto:[email protected]>>:
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:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
--
-- Dmitry Tantsur
--
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
