Open Stack

2015-06-16 21:14 GMT+09:00 Sean Dague <sean at dague.net>:
> On 06/16/2015 07:38 AM, Alex Xu wrote:
>>
>>
>> 2015-06-16 18:57 GMT+08:00 Sean Dague <sean at dague.net
>> <mailto:sean at dague.net>>:
>>
>>     On 06/15/2015 03:45 PM, Kevin L. Mitchell wrote:
>>     > On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote:
>>     >> 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].
>>     >
>>     > Given the disagreement evinced by the responses to this thread, let me
>>     > ask a question: Would there be any particular problem with using
>>     > "X-OpenStack-API-Version"?
>>
>>     So, here is my concern with not having the project namespacing at all:
>>
>>     Our expectation is that services are going to move towards real wsgi on
>>     their API instead of eventlet. Which is, hopefully, naturally going to
>>     give you things like this:
>>
>>     GET api.server/compute/servers
>>     GET api.server/baremetal/chasis
>>
>>     In such a world it will end up possibly confusing that
>>     OpenStack-API-Version 2.500 is returned from api.server/compute/servers,
>>     but OpenStack-API-Version 1.200 is returned from
>>     api.server/baremetal/chasis.
>>
>>
>> Client should get those url from keystone SC, that means client should
>> know what he request to.
>
> Sure, there is a lot of should in there though. But by removing a level
> of explicitness in this we potentially introduce more confusion. The
> goal of a good interface is not just to make it easy to use, but make it
> hard to misuse. Being explicit about the service in the return header
> will eliminate a class of errors where the client code got confused
> about which service they were talking to (because to setup a VM with a
> network in a neutron case you have to jump back and forth between Nova /
> Neutron quite a bit).

Does here mean Nova will be able to pass Neutron's microversion to
Neutron on a single Nova API call?
I feel Nova should not do it because in this case Neutron is a backend
and Neutron should disappear from end user POV on Nova API.
If backend services are not visible from end users POV, the users
cannot know the range of backend service microversions.
And if acceptable to pass microversion to backend service, the out of
microversion range error would happen and that would make users more
confused.

Thanks
Ken Ohmichi