Open Stack

Hi all,

We had a session discussion the future of the Neutron API. The etherpad is
available here:
https://etherpad.openstack.org/p/newton-neutron-future-neutron-api

The first two topics were Keystone V3 and Pecan. Both of those were
relatively straight-forward.

For the switch to Keystone V3, we will need to accept project_id in the API
as well as tenant_id for backward compatibility. Without the adoption of
micro-versioning (more on that below), we will have to support both
indefinitely.

The plan for Pecan is to finish fixing up the last remaining bugs with some
of the service plugins. Once it is passing all tests, we will upgrade the
pecan jobs from experimental to non-voting and then voting (after maybe a
week).

Once we are comfortable that it looks stable, we will switch Neutron to
default to pecan so everything will be running it by default. This may
break some out-of-tree service plugins/extensions so we need to do it early
to address any issues.


Finally, the topic of microversioning came up again. Until we adopt it, we
will have to maintain backward compatibility in all of our responses (so we
would never be able to get rid of tenant_id).

This led to several questions that need to be answered before we can
proceed:

   - Do we have any volunteers to do the microversioning work?
   - Do we drop support for extensions on the switch to microversioning?
   - If we keep extensions, are we okay with them being un-versioned and
   possibly incompatible between implementations?


I think until we get the questions above agreed upon early on, there isn't
much point in getting down into detailed planning because the effort won't
go anywhere without high-level agreement.


Cheers,
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160503/1280677f/attachment.html>