Open Stack

On Mon, Dec 8, 2014 at 1:51 AM, Gary Kotton <gkotton at vmware.com> wrote:
> 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?
>

On the contrary, any effort of refactoring ML2+OVS is totally
meaningless, if the only reason is separating it from Neutron core,
not to say moving it out of tree in the future. In fact the word
"reference implementation" is not so appropriate, "baseline
implementation" is preferred, because ML2+OVS COULD BE used for large
scale commercial deployment already.

Today over half of Openstack users deployed native Neutron/Quantum
built-in backend, especially OVS. Although some are not ML2 based yet,
but they can move to ML2 OVS MD so easily and then enjoy rich features
newly introduced from Ice and Juno. So if we waste time to do some
kind of separation on ML2+OVS, natural question would be: "does the
community want to slow the progress of default built-in
implementation, give more opportunity to 3rd plugin/driver to better
compete with free&open ML2+OVS?"

Although this decomposition spec is highly appreciated, but built-in
OVS separation should be worried and warned, for it would introduce
slower response to customer, then hurt overall competitiveness of our
project. Standalone fast iteration on new features is strongly needed
for our built-in baseline OVS implementation. E.g. I already know a
little customer choose openstack because of exciting OVS-DVR from JUNO
(although in early beta quality yet).

It's not the place to talk about fair play between vendor plugin and
open built-in backend. Fair is only needed between vendors/3rd
controllers, but not needed for the de facto built-in free backend
pervasively adopted. An off-the-shelf built-in backend with fully
tested commercial quality would lay a solid foundation for the success
of our community.

Best Regards,
Loy



> Cause we will fix them quicker as it is something that prevent Neutron from
> moving forwards
> We will just need to fix in one place first and not in N (where N is the
> vendor plugins)
> This is a community effort – so we will have a lot more eyes on it
> It will provide a reference architecture for all new plugins that want to be
> added to the tree
> 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:
>
> Create a stack forge project for ML2
> Create the shim in Neutron
> 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.
> Thanks
> Gary
>
>
> From: "mestery at mestery.com" <mestery at mestery.com>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Sunday, December 7, 2014 at 7:19 PM
> To: OpenStack List <openstack-dev at lists.openstack.org>
> Cc: "openstack at lists.openstack.org" <openstack at 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 Kilo.
>
> Find me on IRC Monday morning and we can discuss further if you still have
> questions and concerns.
>
> Thanks!
> Kyle
>
> On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton <gkotton at vmware.com> wrote:
>>
>> Hi,
>> 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.
>> Thanks
>> Gary
>>
>> From: "Armando M." <armamig at gmail.com>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>> Date: Saturday, December 6, 2014 at 1:04 AM
>> To: OpenStack List <openstack-dev at lists.openstack.org>,
>> "openstack at lists.openstack.org" <openstack at lists.openstack.org>
>> 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 areas:
>>
>> 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,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/134680
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>