<div dir="ltr">Hi,<div><br></div><div>As most of you surely know the proposal for micro versioning in Nova [1] has been approved for Kilo.</div><div>I am sure you are aware that a similar proposal has bee discussed for Neutron at the design summit.</div><div><br></div><div>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.</div><div><br></div><div>However, as usual, the story for Neutron is a bit more complex.</div><div>- 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.</div><div>- 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.</div><div>- 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.</div><div>- The proposed plugin interface refactor [spec not yet available] is also likely to clash with API micro-versioning</div><div><br></div><div>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].</div><div>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]. <br><br></div><div>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].</div><div>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.</div><div><br></div><div>Thanks for reading,<br></div><div>Salvatore</div><div><br></div><div><br></div><div>[1] <a href="http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html">http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html</a></div><div>[2] <a href="https://review.openstack.org/#/c/134680/">https://review.openstack.org/#/c/134680/</a></div><div>[3] <a href="https://review.openstack.org/#/c/136760/">https://review.openstack.org/#/c/136760/</a></div></div>