[openstack-dev] [Neutron] Core API refactoring

Mark McClain mmcclain at yahoo-inc.com
Wed May 21 16:50:41 UTC 2014


On May 21, 2014, at 10:23 AM, Mandeep Dhami <dhami at noironetworks.com<mailto:dhami at noironetworks.com>> wrote:

Hi Sean:

While the APIs might not be changing*, I suspect that there are significant design decisions being made**. These changes are probably more significant than any new feature being discussed. As a community, are we expected to document these design changes and review these changes as well?

There was a bit of high level discussion needed to ensure community consensus before we could dive into the details.  The actual changes will be documented according to Neutron’s spec process.


I am still trying to figure out what Neutron's review standards are. On one hand, I am seeing code review comments that reject a patch for cosmetic changes (like a name change from what was in the reviewed blueprint), to having an attitude that something as core and central to neutron as refactoring and a major API update to v3 not needing a design document/review.

It is my opinion, and my recommendation, that the proposed changes be documented and reviewed by same standard that we have for other features.

That has been the plan all along to follow the spec process as with all other changes to Neutron.


* I believe that v3 API is being introduced and chnages are being made, but I might have mis-understood.

It is important to note that the changes are to the code level interfaces within the neutron-server executable and no user facing REST changes.  The intent is to keep compatibility with existing V2 plugins while moving towards a new V3 plugin architecture.  Our dev cycle is really short, so inserting this new layer will be in preparation for a formal V3 definition declared during the K cycle.  The discussion intentionally avoided any changes to logical and/or db models for this very reason.


** I was under the impression that in addition to the Pecan updates, there was going to be refactoring to use taskflow as well. And that I expect to have significant control flow impact, and that is what I really wanted to review.

Moving towards tasks is actually independent of the changes to the REST layer.  Tasks will refactor the implementation of the actual plugins, but should not require any cooperation with the REST layer.

mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140521/96439b55/attachment.html>


More information about the OpenStack-dev mailing list