Open Stack

On 12 June 2015 at 12:22, Sean Dague <sean at dague.net> wrote:

> 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.
>

Well, we'd have both "extensions" and "revisions" evolving at the same
time. The situation won't be nearly as difficult to handle as nova v3.0,
but it still be a hassle.
While I understand where people advocating for not freezing the current
extension-based mechanisms until microversioning is proved and tested, on
the other hand my concern is that this effort is already on the failure
road as it's pretty much an experimental alternative to the current way of
evolving the API for the foreseeable future.

Therefore I would say that the community might accept that if
microversioning is functionally complete and reliably working in version X
(where X is an openstack release), then automatically the "old" API will be
frozen in the same version, deprecated in X+1 and killed in X+2.



>
> 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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/135defe5/attachment.html>