Hi Kyle,
I am not missing the point. I understand the proposal. I just think that it has 
some shortcomings (unless I misunderstand, which will certainly not be the 
first time and most definitely not the last). The thinning out is to have a 
shim in place. I understand this and this will be the entry point for the 
plugin. I do not have a concern for this. My concern is that we are not doing 
this with the ML2 off the bat. That should lead by example as it is our 
reference architecture. Lets not kid anyone, but we are going to hit some 
problems with the decomposition. I would prefer that it be done with the 
default implementation. Why?

  1.  Cause we will fix them quicker as it is something that prevent Neutron 
from moving forwards
  2.  We will just need to fix in one place first and not in N (where N is the 
vendor plugins)
  3.  This is a community effort – so we will have a lot more eyes on it
  4.  It will provide a reference architecture for all new plugins that want to 
be added to the tree
  5.  It will provide a working example for plugin that are already in tree and 
are to be replaced by the shim

If we really want to do this, we can say freeze all development (which is just 
approvals for patches) for a few days so that we will can just focus on this. I 
stated what I think should be the process on the review. For those who do not 
feel like finding the link:

  1.  Create a stack forge project for ML2
  2.  Create the shim in Neutron
  3.  Update devstack for the to use the two repos and the shim

When #3 is up and running we switch for that to be the gate. Then we start a 
stopwatch on all other plugins.

Sure, I’ll catch you on IRC tomorrow. I guess that you guys will bash out the 
details at the meetup. Sadly I will not be able to attend – so you will have to 
delay on the tar and feathers.

From: "mest...@mestery.com<mailto:mest...@mestery.com>" 
Reply-To: OpenStack List 
Date: Sunday, December 7, 2014 at 7:19 PM
To: OpenStack List 
Cc: "openst...@lists.openstack.org<mailto:openst...@lists.openstack.org>" 
Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

Gary, you are still miss the point of this proposal. Please see my comments in 
review. We are not forcing things out of tree, we are thinning them. The text 
you quoted in the review makes that clear. We will look at further decomposing 
ML2 post Kilo, but we have to be realistic with what we can accomplish during 

Find me on IRC Monday morning and we can discuss further if you still have 
questions and concerns.


On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton 
<gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote:
I have raised my concerns on the proposal. I think that all plugins should be 
treated on an equal footing. My main concern is having the ML2 plugin in tree 
whilst the others will be moved out of tree will be problematic. I think that 
the model will be complete if the ML2 was also out of tree. This will help 
crystalize the idea and make sure that the model works correctly.

From: "Armando M." <arma...@gmail.com<mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
Date: Saturday, December 6, 2014 at 1:04 AM
To: OpenStack List 
Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition

Hi folks,

For a few weeks now the Neutron team has worked tirelessly on [1].

This initiative stems from the fact that as the project matures, evolution of 
processes and contribution guidelines need to evolve with it. This is to ensure 
that the project can keep on thriving in order to meet the needs of an ever 
growing community.

The effort of documenting intentions, and fleshing out the various details of 
the proposal is about to reach an end, and we'll soon kick the tires to put the 
proposal into practice. Since the spec has grown pretty big, I'll try to 
capture the tl;dr below.

If you have any comment please do not hesitate to raise them here and/or reach 
out to us.

tl;dr >>>

>From the Kilo release, we'll initiate a set of steps to change the following 

  *   Code structure: every plugin or driver that exists or wants to exist as 
part of Neutron project is decomposed in an slim vendor integration (which 
lives in the Neutron repo), plus a bulkier vendor library (which lives in an 
independent publicly available repo);
  *   Contribution process: this extends to the following aspects:
     *   Design and Development: the process is largely unchanged for the part 
that pertains the vendor integration; the maintainer team is fully auto 
governed for the design and development of the vendor library;
     *   Testing and Continuous Integration: maintainers will be required to 
support their vendor integration with 3rd CI testing; the requirements for 3rd 
CI testing are largely unchanged;
     *   Defect management: the process is largely unchanged, issues affecting 
the vendor library can be tracked with whichever tool/process the maintainer 
see fit. In cases where vendor library fixes need to be reflected in the vendor 
integration, the usual OpenStack defect management apply.
     *   Documentation: there will be some changes to the way plugins and 
drivers are documented with the intention of promoting discoverability of the 
integrated solutions.
  *   Adoption and transition plan: we strongly advise maintainers to stay 
abreast of the developments of this effort, as their code, their CI, etc will 
be affected. The core team will provide guidelines and support throughout this 
cycle the ensure a smooth transition.

To learn more, please refer to [1].

Many thanks,

[1] https://review.openstack.org/#/c/134680

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to