Open Stack

On 06/11/2015 06:03 PM, Salvatore Orlando wrote:
> As most of you already know, work is beginning to move forward on the
> micro-versioned Neutron API, for which a specification is available at [1]
> 
> From a practical perspective there is one non-negligible preliminary
> issue that needs attention. then Neutron API URI prefix includes the
> full version number - currently 2.0. For instance:
> 
>  http://neutron_server:9696/v2.0/networks.json
> 
> This clearly makes a microversioned approach a bit weird - if you have
> to use, for instance, 2.0 as a URI prefix for API version 2.12.
> On the one hand it might make sense to start the micro-versioned API as
> a sort of clean slate, possibly using a version-agnostic URI prefix or
> no prefix at all; also as pointed out by some community members it will
> give a chance to validate this versioned API approach.
> This will have however the drawback that both the unversioned,
> extension-based so-called 2.0 API will keep living and evolving
> side-by-side with the versioned API, and then switching to the versioned
> API will not be transparent to clients.
> It would be good to receive some opinions from the developer and user
> community on the topic.

It will definitely be challenging to have both evolving at once. The
Nova team had a lot of pains in that happening in the 18 months of v3.0
work. Once we got the microversion mechanism in place we hard froze
v2.0. That being said we actually had 2 internal code bases, so our
situation was a bit gorpier than yours.

On the version in the url: My expectation is at some point the future
we'll privot out of having a version string in our URL entirely, but
it's one of those things that can come later.
The url root is mostly important from a service catalog perspective, in
that what's there matches what the code returns in all it's internal
links. Honestly, long term, it would be great if 1) we actually
developer standards for naming in the service catalog 2) the API
services stop having their API url in code, but instead reflect it back
from the catalog. Which would fix one of the gorpiest parts of putting
your API servers behind haproxy or ssl termination. I.e. I wouldn't be
too concerned on that front, it looks a little funny, but won't really
get in anyone's way.

> Furthermore, another topic that has been brought up is whether plugins
> should be allowed to control the version of the API server, like
> specifying minimum and maximum version. My short answer is no, because
> the plugin should implement the API, not controlling it. Also, the spec
> provides a facility for plugins to disable features if they are unable
> to support them.
> 
> Finally, I received queries from several community members that would be
> keen on helping supporting this microversioning effort. I wonder if the
> PTL and the API lieutenants would ok with agreeing to have a team of
> developers meeting regularly, working towards implementing this feature,
> and report progress and/or issues to the general Neutron meeting.
> 
> Salvatore
> 
> [1] https://review.openstack.org/#/c/136760/
> 
> 
> 
> 
> 
> 
> 
> 
> __________________________________________________________________________
> 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
> 


-- 
Sean Dague
http://dague.net