Open Stack

Hi,

As most of you surely know the proposal for micro versioning in Nova [1]
has been approved for Kilo.
I am sure you are aware that a similar proposal has bee discussed for
Neutron at the design summit.

Considering the direction taken by nova, and the fact that neutron
extensions are becoming unmanageable, I would encourage Neutron to move
away from extensions as a way for evolving the API to versioning. Possibly
something along the lines of what has been approved for [1]. Not
necessarily the same, but it's also worth remembering it is of paramount
importance that versioning is done in the same way for all OpenStack API
endpoints.

However, as usual, the story for Neutron is a bit more complex.
- The work in progress in switching the WSGI framework to Pecan will get
into the way of introducing micro versioning. As we've been planning on
removing the home grown WSGI for a while, it makes sense to give it
priority.
- The neutron API is composed of an API for the core service plus a set of
APIs for advanced services. Therefore sorting out advanced service spin-off
is yet another prerequisite for introducing any form of API versioning.
- It is not yet clear how versioning on the API side should be mapped on
the plugin interface. Ideally one would like to keep plugins independent of
API versioning.
- The proposed plugin interface refactor [spec not yet available] is also
likely to clash with API micro-versioning

Considering the above points, introducing API micro versioning in Kilo is
already a stretch. It therefore makes sense to move towards a more
digestible approach along the lines of what has already been proposed for
the plugin split [2].
We are therefore proposing for Kilo to stop evolving the API through
extension, unless the extensions represents something that can eventually
"spin off" neutron core [3]. Furthermore we'll finally stop calling core
things such as l3 an "extension". The details regarding this proposal are
available in [3].

If you believe that moving away from extensions is a decent idea and that
it's about time we redefined what the core neutron API is, but have any
kind of concern, please comment on [3].
On the other hand, if you reckon that Neutron should keep evolving through
extensions, if you feel that this activity will hinder your team roadmap
for this release cycle, (or if you want to start a flame war on Neutron
APIs and extensions), it might be probably better to discuss on the mailing
list to involve a larger audience.

Thanks for reading,
Salvatore


[1]
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html
[2] https://review.openstack.org/#/c/134680/
[3] https://review.openstack.org/#/c/136760/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141124/ea1562b4/attachment.html>