2015-06-16 21:14 GMT+09:00 Sean Dague <s...@dague.net>: > On 06/16/2015 07:38 AM, Alex Xu wrote: >> >> >> 2015-06-16 18:57 GMT+08:00 Sean Dague <s...@dague.net >> <mailto:s...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
