Open Stack

On Mon, Jun 15, 2015 at 1:24 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 06/15/2015 01:31 PM, Sean Dague wrote:
>
>> On 06/15/2015 01:07 PM, Jay Pipes wrote:
>>
>>> 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 think you are seeing demons where there are none.
>>
>
> I don't think there are any demons anywhere :) Just a lack of
> communication and/or consensus.
>
> > I don't think it was
>
>> ever really clear in the specification that official project short
>> moniker was critical to the spec vs. code name that everyone uses. While
>> I didn't weigh in on the review in question, I wouldn't have really seen
>> an issue with it at the time.
>>
>
> OK.
>
>  Honestly, we should work through standardization of the service catalog
>> (as was discussed at Summit) first and before we push out a microversion
>> on these projects to change this header, especially as that is the hook
>> by which projects are versioning on now.
>>
>
> Sure, good point. Morgan, Adam, where are we on that?
>
>
So we have a x-project-spec with some initial comments [1] from Anne.
Generally speaking I think we've pushed the definition of what goes into
the SC (not a restructure of the catalog as that is API contract impacting)
to the API-WorkingGroup with TC oversight for specific "type"s and their
definitions [2].

So in short:
1) Keystone can't enforce the types (because some types wont be listed)

2) Devstack should be updated to conform to the API-WG / TC oversight of
the "best practices" (aka, nova is "compute", etc)

3) Any urls (aka VersionList? PublicURL? etc) that we want to make default
can be added as long as we maintain the current ones.

4) "Name" for endpoints will be deprecated (but cannot be removed because
of API contract.

5) Keystone will implement a JSON schema to make sure everything does
conform but allow for "Extra" values while we are in the transition period
(for required/changed values). A future catalog type (if it exists) will
see some restructure.

I think the long-term enforcement of type (etc) will fall to Defcore, but
that is after we've made these changes via API-WG and TC.


[1] https://review.openstack.org/#/c/181393/
[2] https://etherpad.openstack.org/p/service-catalog-cross-project-vancouver

Sent via mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/c5f8bad5/attachment.html>