Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Gary Kotton]

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." mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, December 6, 2014 at 1:04 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>, 
"openst...@lists.openstack.org" 
mailto:openst...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Kyle Mestery]

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  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." 
> Reply-To: OpenStack List 
> Date: Saturday, December 6, 2014 at 1:04 AM
> To: OpenStack List , "
> openst...@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Gary Kotton]

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.
Thanks
Gary


From: "mest...@mestery.com<mailto:mest...@mestery.com>" 
mailto:mest...@mestery.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, December 7, 2014 at 7:19 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Cc: "openst...@lists.openstack.org<mailto: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 
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 
mailto:gkot...@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." mailto:arma...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, December 6, 2014 at 1:04 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>, 
"openst...@lists.openstack.org<mailto:openst...@lists.openstack.org>" 
mailto:openst...@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 

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[loy wolfe]

On Mon, Dec 8, 2014 at 1:51 AM, Gary Kotton  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: "mest...@mestery.com" 
> Reply-To: OpenStack List 
> Date: Sunday, December 7, 2014 at 7:19 PM
> To: OpenStack List 
> Cc: "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 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  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

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Maru Newby]

On Dec 7, 2014, at 10:51 AM, Gary Kotton  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?

The proposal is to move vendor-specific logic out of the tree to increase 
vendor control over such code while decreasing load on reviewers.  ML2 doesn’t 
contain vendor-specific logic - that’s the province of ML2 drivers - so it is 
not a good target for the proposed decomposition by itself.


>   • 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.

As was pointed out on the spec (see Miguel’s comment on r15), the ML2 plugin 
and the OVS mechanism driver need to remain in the main Neutron repo for now.  
Neutron gates on ML2+OVS and landing a breaking change in the Neutron repo 
along with its corresponding fix to a separate ML2 repo would be all but 
impossible under the current integrated gating scheme.  Plugins/drivers that do 
not gate Neutron have no such constraint.


Maru


> 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: "mest...@mestery.com" 
> Reply-To: OpenStack List 
> Date: Sunday, December 7, 2014 at 7:19 PM
> To: OpenStack List 
> Cc: "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 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  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." 
>> Reply-To: OpenStack List 
>> Date: Saturday, December 6, 2014 at 1:04 AM
>> To: OpenStack List , 
>> "openst...@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

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Salvatore Orlando]

n
> 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.
>
> As was pointed out on the spec (see Miguel’s comment on r15), the ML2
> plugin and the OVS mechanism driver need to remain in the main Neutron repo
> for now.  Neutron gates on ML2+OVS and landing a breaking change in the
> Neutron repo along with its corresponding fix to a separate ML2 repo would
> be all but impossible under the current integrated gating scheme.
> Plugins/drivers that do not gate Neutron have no such constraint.
>
>
> Maru
>
>
> > 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: "mest...@mestery.com" 
> > Reply-To: OpenStack List 
> > Date: Sunday, December 7, 2014 at 7:19 PM
> > To: OpenStack List 
> > Cc: "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 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  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." 
> >> Reply-To: OpenStack List 
> >> Date: Saturday, December 6, 2014 at 1:04 AM
> >> To: OpenStack List , "
> openst...@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 manage

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Armando M.]

> Thanks for your attention and for reading through this
>
> Salvatore
>
> [1]
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/vmware/plugin.py#n22
>
> On 8 December 2014 at 21:51, Maru Newby  wrote:
>
>>
>> On Dec 7, 2014, at 10:51 AM, Gary Kotton  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?
>>
>> The proposal is to move vendor-specific logic out of the tree to increase
>> vendor control over such code while decreasing load on reviewers.  ML2
>> doesn’t contain vendor-specific logic - that’s the province of ML2 drivers
>> - so it is not a good target for the proposed decomposition by itself.
>>
>>
>> >   • 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.
>>
>> As was pointed out on the spec (see Miguel’s comment on r15), the ML2
>> plugin and the OVS mechanism driver need to remain in the main Neutron repo
>> for now.  Neutron gates on ML2+OVS and landing a breaking change in the
>> Neutron repo along with its corresponding fix to a separate ML2 repo would
>> be all but impossible under the current integrated gating scheme.
>> Plugins/drivers that do not gate Neutron have no such constraint.
>>
>>
>> Maru
>>
>>
>> > 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: "mest...@mestery.com" 
>> > Reply-To: OpenStack List 
>> > Date: Sunday, December 7, 2014 at 7:19 PM
>> > To: OpenStack List 
>> > Cc: "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 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  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
>> >>
>> >>

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Salvatore Orlando]

 they would be accepted only as “thin integration modules”, which
>> ideally should just be a pointer to code living somewhere else. I’m not
>> questioning the validity of this approach, but it has been brought to my
>> attention that this will actually be troubling for teams which have made an
>> investment in the previous release cycles to upstream plugins following the
>> “old” process
>>
> You are not alone. Other efforts went through the same process [1, 2, 3].
> Adjusting is a way of life. No-one is advocating for throwing away existing
> investment. This proposal actually promotes new and pre-existing investment.
>
> [1] https://review.openstack.org/#/c/104452/
> [2] https://review.openstack.org/#/c/103728/
> [3] https://review.openstack.org/#/c/136091/
>
3 - Regarding the above discussion on "ML2 or not ML2". The point on
>> co-gating is well taken. Eventually we'd like to remove this binding -
>> because I believe the ML2 subteam would also like to have more freedom on
>> their plugin. Do we already have an idea about how doing that without
>> completely moving away from the db_base class approach?
>>
> Sure, if you like to participate in the process, we can only welcome you!
>

I actually asked you if you already had an idea... should I take that as a
no?

> Thanks for your attention and for reading through this
>>
>> Salvatore
>>
>> [1]
>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/vmware/plugin.py#n22
>>
>> On 8 December 2014 at 21:51, Maru Newby  wrote:
>>
>>>
>>> On Dec 7, 2014, at 10:51 AM, Gary Kotton  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?
>>>
>>> The proposal is to move vendor-specific logic out of the tree to
>>> increase vendor control over such code while decreasing load on reviewers.
>>> ML2 doesn’t contain vendor-specific logic - that’s the province of ML2
>>> drivers - so it is not a good target for the proposed decomposition by
>>> itself.
>>>
>>>
>>> >   • 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.
>>>
>>> As was pointed out on the spec (see Miguel’s comment on r15), the ML2
>>> plugin and the OVS mechanism driver need to remain in the main Neutron repo
>>> for now.  Neutron gates on ML2+OVS and landing a breaking change in the
>>> Neutron repo along with its corresponding fix to a separate ML2 repo would
>>> be all but impossible under the current integrated gating scheme.
>>> Plugins/drivers that do not gate Neutron have no such constraint.
>>>
>>>
>>> Maru
>>>
>>>
>>> > 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 –

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Ivar Lazzaro]

existing investment.
>>
>> [1] https://review.openstack.org/#/c/104452/
>> [2] https://review.openstack.org/#/c/103728/
>> [3] https://review.openstack.org/#/c/136091/
>>
> 3 - Regarding the above discussion on "ML2 or not ML2". The point on
>>> co-gating is well taken. Eventually we'd like to remove this binding -
>>> because I believe the ML2 subteam would also like to have more freedom on
>>> their plugin. Do we already have an idea about how doing that without
>>> completely moving away from the db_base class approach?
>>>
>> Sure, if you like to participate in the process, we can only welcome you!
>>
>
> I actually asked you if you already had an idea... should I take that as a
> no?
>
>> Thanks for your attention and for reading through this
>>>
>>> Salvatore
>>>
>>> [1]
>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/vmware/plugin.py#n22
>>>
>>> On 8 December 2014 at 21:51, Maru Newby  wrote:
>>>
>>>>
>>>> On Dec 7, 2014, at 10:51 AM, Gary Kotton  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?
>>>>
>>>> The proposal is to move vendor-specific logic out of the tree to
>>>> increase vendor control over such code while decreasing load on reviewers.
>>>> ML2 doesn’t contain vendor-specific logic - that’s the province of ML2
>>>> drivers - so it is not a good target for the proposed decomposition by
>>>> itself.
>>>>
>>>>
>>>> >   • 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.
>>>>
>>>> As was pointed out on the spec (see Miguel’s comment on r15), the ML2
>>>> plugin and the OVS mechanism driver need to remain in the main Neutron repo
>>>> for now.  Neutron gates on ML2+OVS and landing a breaking change in the
>>>> Neutron repo along with its corresponding fix to a separate ML2 repo would
>>>> be all but impossible under the current integrated gating scheme.
>>>> Plugins/drivers that do not gate Neutron have no such constraint.
>>>>
>>>>
>>>> Maru
>>>>
>>>>
>>>> > 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: "mest...@mestery.com" 
>>>> > Reply-To: OpenStack List 
>>>> > Date: Sunday, December 

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Armando M.]

plit out).
>>>>
>>> No new plugins can and will be accepted if they do not adopt the
>>> proposed model, let's be very clear about this.
>>>
>>
>> This is also what I gathered from the proposal. It seems that you're
>> however stating that there might be some flexibility in defining how much a
>> plugin complies with the new model. I will need to go back to the drawing
>> board with the rest of my team and see in which way this can work for us.
>>
>>
>>> The questions I would like to bring to the wider community are therefore
>>>> the following:
>>>>
>>>> 1 - Is there a possibility of making a further concession on the
>>>> current proposal, where maintainers are encouraged to experiment with the
>>>> plugin split in Kilo, but will actually required to do it in the next
>>>> release?
>>>>
>>> This is exactly what the spec is proposing: get started now, and it does
>>> not matter if you don't finish in time.
>>>
>>
>> I think the deprecation note at line 416 still scares people off a bit.
>> To me your word is enough, no change is needed.
>>
>>> 2 - What could be considered as a acceptable as a new plugin? I
>>>> understand that they would be accepted only as “thin integration modules”,
>>>> which ideally should just be a pointer to code living somewhere else. I’m
>>>> not questioning the validity of this approach, but it has been brought to
>>>> my attention that this will actually be troubling for teams which have made
>>>> an investment in the previous release cycles to upstream plugins following
>>>> the “old” process
>>>>
>>> You are not alone. Other efforts went through the same process [1, 2,
>>> 3]. Adjusting is a way of life. No-one is advocating for throwing away
>>> existing investment. This proposal actually promotes new and pre-existing
>>> investment.
>>>
>>> [1] https://review.openstack.org/#/c/104452/
>>> [2] https://review.openstack.org/#/c/103728/
>>> [3] https://review.openstack.org/#/c/136091/
>>>
>> 3 - Regarding the above discussion on "ML2 or not ML2". The point on
>>>> co-gating is well taken. Eventually we'd like to remove this binding -
>>>> because I believe the ML2 subteam would also like to have more freedom on
>>>> their plugin. Do we already have an idea about how doing that without
>>>> completely moving away from the db_base class approach?
>>>>
>>> Sure, if you like to participate in the process, we can only welcome
>>> you!
>>>
>>
>> I actually asked you if you already had an idea... should I take that as
>> a no?
>>
>>> Thanks for your attention and for reading through this
>>>>
>>>> Salvatore
>>>>
>>>> [1]
>>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/vmware/plugin.py#n22
>>>>
>>>> On 8 December 2014 at 21:51, Maru Newby  wrote:
>>>>
>>>>>
>>>>> On Dec 7, 2014, at 10:51 AM, Gary Kotton  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?
>>>>>
>>>>> The proposal is to move vendor-specific logic out of the tree to
>>>>> increase vendor control over such code while decreasing load on reviewers.
>>>>> ML2 doesn’t contain vendor-specific logic - that’s the province of ML2
>>>>> drivers - so it is not a good target for the proposed decomposition by
>>>>> itself.
>>>>>
>>>>>
>>>>> >   • Cause we will fix them quicker as it is something that
>>>>> 

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Vadivel Poonathan]

[1] https://review.openstack.org/#/c/104452/
>>>> [2] https://review.openstack.org/#/c/103728/
>>>> [3] https://review.openstack.org/#/c/136091/
>>>>
>>> 3 - Regarding the above discussion on "ML2 or not ML2". The point on
>>>>> co-gating is well taken. Eventually we'd like to remove this binding -
>>>>> because I believe the ML2 subteam would also like to have more freedom on
>>>>> their plugin. Do we already have an idea about how doing that without
>>>>> completely moving away from the db_base class approach?
>>>>>
>>>> Sure, if you like to participate in the process, we can only welcome
>>>> you!
>>>>
>>>
>>> I actually asked you if you already had an idea... should I take that as
>>> a no?
>>>
>>>> Thanks for your attention and for reading through this
>>>>>
>>>>> Salvatore
>>>>>
>>>>> [1]
>>>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/vmware/plugin.py#n22
>>>>>
>>>>> On 8 December 2014 at 21:51, Maru Newby  wrote:
>>>>>
>>>>>>
>>>>>> On Dec 7, 2014, at 10:51 AM, Gary Kotton  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?
>>>>>>
>>>>>> The proposal is to move vendor-specific logic out of the tree to
>>>>>> increase vendor control over such code while decreasing load on 
>>>>>> reviewers.
>>>>>> ML2 doesn’t contain vendor-specific logic - that’s the province of ML2
>>>>>> drivers - so it is not a good target for the proposed decomposition by
>>>>>> itself.
>>>>>>
>>>>>>
>>>>>> >   • 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.
>>>>>>
>>>>>> As was pointed out on the spec (see Miguel’s comment on r15), the ML2
>>>>>> plugin and the OVS mechanism driver need to remain in the main Neutron 
>>>>>> repo
>>>>>> for now.  Neutron gates on ML2+OVS and landing a breaking change in the
>>>>>> Neutron repo along with its corresponding fix to a separate ML2 repo 
>>>>>> w

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Ivar Lazzaro]

promotes new and pre-existing
>>>> investment.
>>>>
>>>> [1] https://review.openstack.org/#/c/104452/
>>>> [2] https://review.openstack.org/#/c/103728/
>>>> [3] https://review.openstack.org/#/c/136091/
>>>>
>>> 3 - Regarding the above discussion on "ML2 or not ML2". The point on
>>>>> co-gating is well taken. Eventually we'd like to remove this binding -
>>>>> because I believe the ML2 subteam would also like to have more freedom on
>>>>> their plugin. Do we already have an idea about how doing that without
>>>>> completely moving away from the db_base class approach?
>>>>>
>>>> Sure, if you like to participate in the process, we can only welcome
>>>> you!
>>>>
>>>
>>> I actually asked you if you already had an idea... should I take that as
>>> a no?
>>>
>>>> Thanks for your attention and for reading through this
>>>>>
>>>>> Salvatore
>>>>>
>>>>> [1]
>>>>> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/vmware/plugin.py#n22
>>>>>
>>>>> On 8 December 2014 at 21:51, Maru Newby  wrote:
>>>>>
>>>>>>
>>>>>> On Dec 7, 2014, at 10:51 AM, Gary Kotton  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?
>>>>>>
>>>>>> The proposal is to move vendor-specific logic out of the tree to
>>>>>> increase vendor control over such code while decreasing load on 
>>>>>> reviewers.
>>>>>> ML2 doesn’t contain vendor-specific logic - that’s the province of ML2
>>>>>> drivers - so it is not a good target for the proposed decomposition by
>>>>>> itself.
>>>>>>
>>>>>>
>>>>>> >   • 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.
>>>>>>
>>>>>> As was pointed out on the spec (see Miguel’s comment on r15), the ML2
>>>>>> plugin and the OVS mechanism driver need to remain in the main Neutron 
>>>>>> repo
>>>>>> for now.  Neutron gates on ML2+OVS and landing a breaking change in the
>>>>>> Neutron repo along with its c

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[loy wolfe]

Remove everything out of tree, and leave only Neutron API framework as
integration platform, would lower the attractions of the whole
Openstack Project. Without a default "good enough" reference backend
from community, customers have to depends on packagers to fully test
all backends for them. Can we image nova without kvm, glance without
swift? Cinder is weak because of default lvm backend, if in the future
Ceph became the default it would be much better.

If the goal of this decomposition is eventually moving default
reference driver out, and the in-tree OVS backend is an eyesore, then
it's better to split the Neutron core with base repo and vendor repo.
They only share common base API/DB model, each vendor can extend their
API, DB model freely, using a shim proxy to delegate all the service
logic to their backend controller. They can choose to keep out of
tree, or in tree (vendor repo) with the previous policy that
contribute code reviewing for their code being reviewed by other
vendors.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Kevin Benton]

>Remove everything out of tree, and leave only Neutron API framework as 
>integration
platform, would lower the attractions of the whole Openstack Project.
Without a default "good enough" reference backend from community, customers
have to depends on packagers to fully test all backends for them.

That's not what's being proposed. Please read the spec.
There will still be a tested reference implementation from the community
that gates all changes. Where the code lives has no impact on customers.

On Wed, Dec 10, 2014 at 12:32 AM, loy wolfe  wrote:

> Remove everything out of tree, and leave only Neutron API framework as
> integration platform, would lower the attractions of the whole
> Openstack Project. Without a default "good enough" reference backend
> from community, customers have to depends on packagers to fully test
> all backends for them. Can we image nova without kvm, glance without
> swift? Cinder is weak because of default lvm backend, if in the future
> Ceph became the default it would be much better.
>
> If the goal of this decomposition is eventually moving default
> reference driver out, and the in-tree OVS backend is an eyesore, then
> it's better to split the Neutron core with base repo and vendor repo.
> They only share common base API/DB model, each vendor can extend their
> API, DB model freely, using a shim proxy to delegate all the service
> logic to their backend controller. They can choose to keep out of
> tree, or in tree (vendor repo) with the previous policy that
> contribute code reviewing for their code being reviewed by other
> vendors.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Cedric OLLIVIER]

 

2014-12-09 18:32 GMT+01:00 Armando M. :

>
> By the way, if Kyle can do it in his teeny tiny time that he has left
> after his PTL duties, then anyone can do it! :)
>
> https://review.openstack.org/#/c/140191/
>
> Fully cloning Dave Tucker's repository [1] and the outdated fork of the
ODL ML2 MechanismDriver included raises some questions (e.g. [2]).
I wish the next patch set removes some files. At least it should take the
mainstream work into account (e.g. [3]) .

[1] https://github.com/dave-tucker/odl-neutron-drivers
[2] https://review.openstack.org/#/c/113330/
[3] https://review.openstack.org/#/c/96459/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

+100. I vote -1 there and would like to point out that we *must* keep
history during the split, and split from u/s code base, not random
repositories. If you don't know how to achieve this, ask oslo people,
they did it plenty of times when graduating libraries from oslo-incubator.
/Ihar

On 10/12/14 19:18, Cedric OLLIVIER wrote:
> 
> 
> 2014-12-09 18:32 GMT+01:00 Armando M.  >:
> 
> 
> By the way, if Kyle can do it in his teeny tiny time that he has 
> left after his PTL duties, then anyone can do it! :)
> 
> https://review.openstack.org/#/c/140191/
> 
> Fully cloning Dave Tucker's repository [1] and the outdated fork of
> the ODL ML2 MechanismDriver included raises some questions (e.g.
> [2]). I wish the next patch set removes some files. At least it
> should take the mainstream work into account (e.g. [3]) .
> 
> [1] https://github.com/dave-tucker/odl-neutron-drivers [2]
> https://review.openstack.org/#/c/113330/ [3]
> https://review.openstack.org/#/c/96459/
> 
> 
> ___ OpenStack-dev
> mailing list OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI
ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY
E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349
PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl
l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx
lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM=
=dfe/
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Gary Kotton]

On 12/11/14, 12:50 PM, "Ihar Hrachyshka"  wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>+100. I vote -1 there and would like to point out that we *must* keep
>history during the split, and split from u/s code base, not random
>repositories. If you don't know how to achieve this, ask oslo people,
>they did it plenty of times when graduating libraries from oslo-incubator.
>/Ihar
>
>On 10/12/14 19:18, Cedric OLLIVIER wrote:
>> 
>> 
>> 2014-12-09 18:32 GMT+01:00 Armando M. > >:
>> 
>> 
>> By the way, if Kyle can do it in his teeny tiny time that he has
>> left after his PTL duties, then anyone can do it! :)
>> 
>> https://review.openstack.org/#/c/140191/

This patch looses the recent hacking changes that we have made. This is a
slight example to try and highly the problem that we may incur as a
community.

>> 
>> Fully cloning Dave Tucker's repository [1] and the outdated fork of
>> the ODL ML2 MechanismDriver included raises some questions (e.g.
>> [2]). I wish the next patch set removes some files. At least it
>> should take the mainstream work into account (e.g. [3]) .
>> 
>> [1] https://github.com/dave-tucker/odl-neutron-drivers [2]
>> https://review.openstack.org/#/c/113330/ [3]
>> https://review.openstack.org/#/c/96459/
>> 
>> 
>> ___ OpenStack-dev
>> mailing list OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>-BEGIN PGP SIGNATURE-
>Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>
>iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI
>ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY
>E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349
>PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl
>l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx
>lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM=
>=dfe/
>-END PGP SIGNATURE-
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Yuriy Shovkoplias]

Dear neutron community,

Can you please clarify couple points on the vendor code decomposition?
 - Assuming I would like to create the new driver now (Kilo development
cycle) - is it already allowed (or mandatory) to follow the new process?

https://review.openstack.org/#/c/134680/

- Assuming the new process is already in place, are the following
guidelines still applicable for the vendor integration code (not for vendor
library)?

https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
The following is a list of requirements for inclusion of code upstream:

   - Participation in Neutron meetings, IRC channels, and email lists.
   - A member of the plugin/driver team participating in code reviews of
   other upstream code.

Regards,
Yuri

On Thu, Dec 11, 2014 at 3:23 AM, Gary Kotton  wrote:
>
>
> On 12/11/14, 12:50 PM, "Ihar Hrachyshka"  wrote:
>
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA512
> >
> >+100. I vote -1 there and would like to point out that we *must* keep
> >history during the split, and split from u/s code base, not random
> >repositories. If you don't know how to achieve this, ask oslo people,
> >they did it plenty of times when graduating libraries from oslo-incubator.
> >/Ihar
> >
> >On 10/12/14 19:18, Cedric OLLIVIER wrote:
> >> 
> >>
> >> 2014-12-09 18:32 GMT+01:00 Armando M.  >> >:
> >>
> >>
> >> By the way, if Kyle can do it in his teeny tiny time that he has
> >> left after his PTL duties, then anyone can do it! :)
> >>
> >> https://review.openstack.org/#/c/140191/
>
> This patch looses the recent hacking changes that we have made. This is a
> slight example to try and highly the problem that we may incur as a
> community.
>
> >>
> >> Fully cloning Dave Tucker's repository [1] and the outdated fork of
> >> the ODL ML2 MechanismDriver included raises some questions (e.g.
> >> [2]). I wish the next patch set removes some files. At least it
> >> should take the mainstream work into account (e.g. [3]) .
> >>
> >> [1] https://github.com/dave-tucker/odl-neutron-drivers [2]
> >> https://review.openstack.org/#/c/113330/ [3]
> >> https://review.openstack.org/#/c/96459/
> >>
> >>
> >> ___ OpenStack-dev
> >> mailing list OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >-BEGIN PGP SIGNATURE-
> >Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> >
> >iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI
> >ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY
> >E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349
> >PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl
> >l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx
> >lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM=
> >=dfe/
> >-END PGP SIGNATURE-
> >
> >___
> >OpenStack-dev mailing list
> >OpenStack-dev@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Armando M.]

On 12 December 2014 at 23:01, Yuriy Shovkoplias 
wrote:
>
> Dear neutron community,
>
> Can you please clarify couple points on the vendor code decomposition?
>  - Assuming I would like to create the new driver now (Kilo development
> cycle) - is it already allowed (or mandatory) to follow the new process?
>
> https://review.openstack.org/#/c/134680/
>
>
Yes. See [1] for more details.


> - Assuming the new process is already in place, are the following
> guidelines still applicable for the vendor integration code (not for vendor
> library)?
>
> https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
> The following is a list of requirements for inclusion of code upstream:
>
>- Participation in Neutron meetings, IRC channels, and email lists.
>- A member of the plugin/driver team participating in code reviews of
>other upstream code.
>
>
I see no reason why you wouldn't follow those guidelines, as a general rule
of thumb. Having said that, some of the wording would need to be tweaked to
take into account of the new contribution model. Bear in mind, that I
started adding some developer documentation in [2], to give a practical
guide to the proposal. More to follow.

Cheers,
Armando

[1]
http://docs-draft.openstack.org/80/134680/17/check/gate-neutron-specs-docs/2a7afdd/doc/build/html/specs/kilo/core-vendor-decomposition.html#adoption-and-deprecation-policy
[2]
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/core-vendor-decomposition,n,z


> Regards,
> Yuri
>
> On Thu, Dec 11, 2014 at 3:23 AM, Gary Kotton  wrote:
>>
>>
>> On 12/11/14, 12:50 PM, "Ihar Hrachyshka"  wrote:
>>
>> >-BEGIN PGP SIGNED MESSAGE-
>> >Hash: SHA512
>> >
>> >+100. I vote -1 there and would like to point out that we *must* keep
>> >history during the split, and split from u/s code base, not random
>> >repositories. If you don't know how to achieve this, ask oslo people,
>> >they did it plenty of times when graduating libraries from
>> oslo-incubator.
>> >/Ihar
>> >
>> >On 10/12/14 19:18, Cedric OLLIVIER wrote:
>> >> 
>> >>
>> >> 2014-12-09 18:32 GMT+01:00 Armando M. > >> >:
>> >>
>> >>
>> >> By the way, if Kyle can do it in his teeny tiny time that he has
>> >> left after his PTL duties, then anyone can do it! :)
>> >>
>> >> https://review.openstack.org/#/c/140191/
>>
>> This patch looses the recent hacking changes that we have made. This is a
>> slight example to try and highly the problem that we may incur as a
>> community.
>>
>> >>
>> >> Fully cloning Dave Tucker's repository [1] and the outdated fork of
>> >> the ODL ML2 MechanismDriver included raises some questions (e.g.
>> >> [2]). I wish the next patch set removes some files. At least it
>> >> should take the mainstream work into account (e.g. [3]) .
>> >>
>> >> [1] https://github.com/dave-tucker/odl-neutron-drivers [2]
>> >> https://review.openstack.org/#/c/113330/ [3]
>> >> https://review.openstack.org/#/c/96459/
>> >>
>> >>
>> >> ___ OpenStack-dev
>> >> mailing list OpenStack-dev@lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >-BEGIN PGP SIGNATURE-
>> >Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>> >
>> >iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI
>> >ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY
>> >E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349
>> >PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl
>> >l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx
>> >lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM=
>> >=dfe/
>> >-END PGP SIGNATURE-
>> >
>> >___
>> >OpenStack-dev mailing list
>> >OpenStack-dev@lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Stefano Maffulli]

On 12/09/2014 04:11 PM,  by wrote:
>>>[vad] how about the documentation in this case?... bcos it needs some
> place to document (a short desc and a link to vendor page) or list these
> kind of out-of-tree plugins/drivers...  just to make the user aware of
> the availability of such plugins/driers which is compatible with so and
> so openstack release.  
> I checked with the documentation team and according to them, only the
> following plugins/drivers only will get documented...
> 1) in-tree plugins/drivers (full documentation) 
> 2) third-party plugins/drivers (ie, one implements and follows this new
> proposal, a.k.a partially-in-tree due to the integration module/code)...
> 
> *** no listing/mention about such completely out-of-tree plugins/drivers***

Discoverability of documentation is a serious issue. As I commented on
docs spec [1], I think there are already too many places, mini-sites and
random pages holding information that is relevant to users. We should
make an effort to keep things discoverable, even if not maintained
necessarily by the same, single team.

I think the docs team means that they are not able to guarantee
documentation for third-party *themselves* (and has not been able, too).
The docs team is already overworked as it is now, they can't take on
more responsibilities.

So once Neutron's code will be split, documentation for the users of all
third-party modules should find a good place to live in, indexed and
searchable together where the rest of the docs are. I'm hoping that we
can find a place (ideally under docs.openstack.org?) where third-party
documentation can live and be maintained by the teams responsible for
the code, too.

Thoughts?

/stef

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Neil Jerram]

Stefano Maffulli  writes:

> On 12/09/2014 04:11 PM,  by wrote:
[vad] how about the documentation in this case?... bcos it needs some
>> place to document (a short desc and a link to vendor page) or list these
>> kind of out-of-tree plugins/drivers...  just to make the user aware of
>> the availability of such plugins/driers which is compatible with so and
>> so openstack release.  
>> I checked with the documentation team and according to them, only the
>> following plugins/drivers only will get documented...
>> 1) in-tree plugins/drivers (full documentation) 
>> 2) third-party plugins/drivers (ie, one implements and follows this new
>> proposal, a.k.a partially-in-tree due to the integration module/code)...
>> 
>> *** no listing/mention about such completely out-of-tree plugins/drivers***
>
> Discoverability of documentation is a serious issue. As I commented on
> docs spec [1], I think there are already too many places, mini-sites and
> random pages holding information that is relevant to users. We should
> make an effort to keep things discoverable, even if not maintained
> necessarily by the same, single team.
>
> I think the docs team means that they are not able to guarantee
> documentation for third-party *themselves* (and has not been able, too).
> The docs team is already overworked as it is now, they can't take on
> more responsibilities.
>
> So once Neutron's code will be split, documentation for the users of all
> third-party modules should find a good place to live in, indexed and
> searchable together where the rest of the docs are. I'm hoping that we
> can find a place (ideally under docs.openstack.org?) where third-party
> documentation can live and be maintained by the teams responsible for
> the code, too.
>
> Thoughts?

I suggest a simple table, under docs.openstack.org, where each row has
the plugin/driver name, and then links to the documentation and code.
There should ideally be a very lightweight process for vendors to add
their row(s) to this table, and to edit those rows.

I don't think it makes sense for the vendor documentation itself to be
under docs.openstack.org, while the code is out of tree.

Regards,
Neil


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Anne Gentle]

On Tue, Dec 16, 2014 at 4:05 AM, Neil Jerram 
wrote:
>
> Stefano Maffulli  writes:
>
> > On 12/09/2014 04:11 PM,  by wrote:
> [vad] how about the documentation in this case?... bcos it needs some
> >> place to document (a short desc and a link to vendor page) or list these
> >> kind of out-of-tree plugins/drivers...  just to make the user aware of
> >> the availability of such plugins/driers which is compatible with so and
> >> so openstack release.
> >> I checked with the documentation team and according to them, only the
> >> following plugins/drivers only will get documented...
> >> 1) in-tree plugins/drivers (full documentation)
> >> 2) third-party plugins/drivers (ie, one implements and follows this new
> >> proposal, a.k.a partially-in-tree due to the integration module/code)...
> >>
> >> *** no listing/mention about such completely out-of-tree
> plugins/drivers***
> >
> > Discoverability of documentation is a serious issue. As I commented on
> > docs spec [1], I think there are already too many places, mini-sites and
> > random pages holding information that is relevant to users. We should
> > make an effort to keep things discoverable, even if not maintained
> > necessarily by the same, single team.
> >
> > I think the docs team means that they are not able to guarantee
> > documentation for third-party *themselves* (and has not been able, too).
> > The docs team is already overworked as it is now, they can't take on
> > more responsibilities.
> >
> > So once Neutron's code will be split, documentation for the users of all
> > third-party modules should find a good place to live in, indexed and
> > searchable together where the rest of the docs are. I'm hoping that we
> > can find a place (ideally under docs.openstack.org?) where third-party
> > documentation can live and be maintained by the teams responsible for
> > the code, too.
> >
> > Thoughts?
>
> I suggest a simple table, under docs.openstack.org, where each row has
> the plugin/driver name, and then links to the documentation and code.
> There should ideally be a very lightweight process for vendors to add
> their row(s) to this table, and to edit those rows.
>
> I don't think it makes sense for the vendor documentation itself to be
> under docs.openstack.org, while the code is out of tree.
>
>
Stef has suggested docs.openstack.org/third-party as a potential location
on the review at [1] https://review.openstack.org/#/c/133372/.

The proposal currently is that the list's source would be in the
openstack-manuals repository, and the process for adding to that repo is
the same as all OpenStack contributions.

I plan to finalize the plan in January, thanks all for the input, and keep
it coming.

Anne


> Regards,
> Neil
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev