Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Édouard Thuleau]

HI Armando,

I opened a launchpad bug [1]. I'll try to propose a patch on one of
the service plugin to enable plugable backend driver.
I'll look how we can add tests to check service plugin works with a
dummy core plugin not based on the Neutron model.

[1] https://bugs.launchpad.net/neutron/+bug/1700651

Édouard.

On Thu, Jun 22, 2017 at 11:40 PM, Armando M.  wrote:
>
>
> On 22 June 2017 at 17:24, Édouard Thuleau  wrote:
>>
>> Hi Armando,
>>
>> I did not opened any bug report. But if a core plugin implements only
>> the NeutronPluginBaseV2 interface [1] and not the NeutronDbPluginV2
>> interface [2], most of the service plugins of that list will be
>> initialized without any errors (only the timestamp plugin fails to
>> initialize because it tries to do DB stuff in its constructor [3]).
>> And all API extensions of that service plugins are listed as supported
>> but none of them works. Resources are not extended (tag, revision,
>> auto-allocate) or some API extensions returns 404
>> (network-ip-availability or flavors).
>>
>> What I proposed, is to improve all that service plugins of that list
>> to be able to support pluggable backend drivers (thanks to the Neutron
>> service driver mechanism [4]) and uses by default a driver based on
>> the Neutron DB(like it's implemented actually). That will permits core
>> plugin which not implements the Neutron DB model to provide its own
>> driver. But until all service plugins will be fixed, I proposed a
>> workaround to disable them.
>
>
> I would recommend against the workaround of disabling them because of the
> stated rationale.
>
> Can you open a bug report, potentially when you're ready to file a fix (or
> enable someone else to take ownership of the fix)? This way we can have a
> more effective conversation either on the bug report or code review.
>
> Thanks,
> Armando
>
>>
>>
>> [1]
>> https://github.com/openstack/neutron/blob/master/neutron/neutron_plugin_base_v2.py#L30
>> [2]
>> https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L124
>> [3]
>> https://github.com/openstack/neutron/blob/master/neutron/services/timestamp/timestamp_plugin.py#L32
>> [4]
>> https://github.com/openstack/neutron/blob/master/neutron/services/service_base.py#L27
>>
>> Édouard.
>>
>> On Thu, Jun 22, 2017 at 12:29 AM, Armando M.  wrote:
>> >
>> >
>> > On 21 June 2017 at 17:40, Édouard Thuleau 
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> @Chaoyi,
>> >> I don't want to change the core plugin interface. But I'm not sure we
>> >> are talking about the same interface. I had a very quick look into the
>> >> tricycle code and I think it uses the NeutronDbPluginV2 interface [1]
>> >> which implements the Neutron DB model. Our Contrail Neutron plugin
>> >> implements the NeutronPluginBaseV2 interface [2]. Anyway,
>> >> NeutronDbPluginV2 is inheriting from NeutronPluginBaseV2 [3].
>> >> Thanks for the pointer to the stadium paragraph.
>> >
>> >
>> > Is there any bug report that captures the actual error you're facing?
>> > Out of
>> > the list of plugins that have been added to that list over time, most
>> > work
>> > just exercising the core plugin API, and we can look into the ones that
>> > don't to figure out whether we overlooked some design abstractions
>> > during
>> > code review.
>> >
>> >>
>> >>
>> >> @Kevin,
>> >> Service plugins loaded by default are defined in a contant list [4]
>> >> and I don't see how I can remove a default service plugin to be loaded
>> >> [5].
>> >>
>> >> [1]
>> >>
>> >> https://github.com/openstack/tricircle/blob/master/tricircle/network/central_plugin.py#L128
>> >> [2]
>> >>
>> >> https://github.com/Juniper/contrail-neutron-plugin/blob/master/neutron_plugin_contrail/plugins/opencontrail/contrail_plugin_base.py#L113
>> >> [3]
>> >>
>> >> https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L125
>> >> [4]
>> >>
>> >> https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43
>> >> [5]
>> >>
>> >> https://github.com/openstack/neutron/blob/master/neutron/manager.py#L190
>> >>
>> >> Édouard.
>> >>
>> >> On Wed, Jun 21, 2017 at 11:22 AM, Kevin Benton 
>> >> wrote:
>> >> > Why not just delete the service plugins you don't support from the
>> >> > default
>> >> > plugins dict?
>> >> >
>> >> > On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> Ok, we would like to help on that. How we can start?
>> >> >>
>> >> >> I think the issue I raise in that thread must be the first point to
>> >> >> address and my second proposition seems to be the correct one. What
>> >> >> do
>> >> >> you think?
>> >> >> But it will needs some time and not sure we'll be able to fix all
>> >> >> service plugins loaded by default before the next Pike release.
>> >> >>
>> >> >> I like to propose a workaround until all default service 

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Armando M.]

On 22 June 2017 at 17:24, Édouard Thuleau  wrote:

> Hi Armando,
>
> I did not opened any bug report. But if a core plugin implements only
> the NeutronPluginBaseV2 interface [1] and not the NeutronDbPluginV2
> interface [2], most of the service plugins of that list will be
> initialized without any errors (only the timestamp plugin fails to
> initialize because it tries to do DB stuff in its constructor [3]).
> And all API extensions of that service plugins are listed as supported
> but none of them works. Resources are not extended (tag, revision,
> auto-allocate) or some API extensions returns 404
> (network-ip-availability or flavors).
>
> What I proposed, is to improve all that service plugins of that list
> to be able to support pluggable backend drivers (thanks to the Neutron
> service driver mechanism [4]) and uses by default a driver based on
> the Neutron DB(like it's implemented actually). That will permits core
> plugin which not implements the Neutron DB model to provide its own
> driver. But until all service plugins will be fixed, I proposed a
> workaround to disable them.
>

I would recommend against the workaround of disabling them because of the
stated rationale.

Can you open a bug report, potentially when you're ready to file a fix (or
enable someone else to take ownership of the fix)? This way we can have a
more effective conversation either on the bug report or code review.

Thanks,
Armando


>
> [1] https://github.com/openstack/neutron/blob/master/neutron/
> neutron_plugin_base_v2.py#L30
> [2] https://github.com/openstack/neutron/blob/master/neutron/
> db/db_base_plugin_v2.py#L124
> [3] https://github.com/openstack/neutron/blob/master/neutron/
> services/timestamp/timestamp_plugin.py#L32
> [4] https://github.com/openstack/neutron/blob/master/neutron/
> services/service_base.py#L27
>
> Édouard.
>
> On Thu, Jun 22, 2017 at 12:29 AM, Armando M.  wrote:
> >
> >
> > On 21 June 2017 at 17:40, Édouard Thuleau 
> wrote:
> >>
> >> Hi,
> >>
> >> @Chaoyi,
> >> I don't want to change the core plugin interface. But I'm not sure we
> >> are talking about the same interface. I had a very quick look into the
> >> tricycle code and I think it uses the NeutronDbPluginV2 interface [1]
> >> which implements the Neutron DB model. Our Contrail Neutron plugin
> >> implements the NeutronPluginBaseV2 interface [2]. Anyway,
> >> NeutronDbPluginV2 is inheriting from NeutronPluginBaseV2 [3].
> >> Thanks for the pointer to the stadium paragraph.
> >
> >
> > Is there any bug report that captures the actual error you're facing?
> Out of
> > the list of plugins that have been added to that list over time, most
> work
> > just exercising the core plugin API, and we can look into the ones that
> > don't to figure out whether we overlooked some design abstractions during
> > code review.
> >
> >>
> >>
> >> @Kevin,
> >> Service plugins loaded by default are defined in a contant list [4]
> >> and I don't see how I can remove a default service plugin to be loaded
> >> [5].
> >>
> >> [1]
> >> https://github.com/openstack/tricircle/blob/master/
> tricircle/network/central_plugin.py#L128
> >> [2]
> >> https://github.com/Juniper/contrail-neutron-plugin/blob/
> master/neutron_plugin_contrail/plugins/opencontrail/
> contrail_plugin_base.py#L113
> >> [3]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> db/db_base_plugin_v2.py#L125
> >> [4]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> plugins/common/constants.py#L43
> >> [5]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> manager.py#L190
> >>
> >> Édouard.
> >>
> >> On Wed, Jun 21, 2017 at 11:22 AM, Kevin Benton 
> wrote:
> >> > Why not just delete the service plugins you don't support from the
> >> > default
> >> > plugins dict?
> >> >
> >> > On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau
> >> > 
> >> > wrote:
> >> >>
> >> >> Ok, we would like to help on that. How we can start?
> >> >>
> >> >> I think the issue I raise in that thread must be the first point to
> >> >> address and my second proposition seems to be the correct one. What
> do
> >> >> you think?
> >> >> But it will needs some time and not sure we'll be able to fix all
> >> >> service plugins loaded by default before the next Pike release.
> >> >>
> >> >> I like to propose a workaround until all default service plugins will
> >> >> be compatible with non-DB core plugins. We can continue to load that
> >> >> default service plugins list but authorizing a core plugin to disable
> >> >> it completely with a private attribut on the core plugin class like
> >> >> it's done for bulk/pagination/sorting operations.
> >> >>
> >> >> Of course, we need to add the ability to report any regression on
> >> >> that. I think unit tests will help and we can also work on a
> >> >> functional test based on a fake non-DB core plugin.
> >> >>
> >> >> Regards,
> >> 

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Édouard Thuleau]

Hi Armando,

I did not opened any bug report. But if a core plugin implements only
the NeutronPluginBaseV2 interface [1] and not the NeutronDbPluginV2
interface [2], most of the service plugins of that list will be
initialized without any errors (only the timestamp plugin fails to
initialize because it tries to do DB stuff in its constructor [3]).
And all API extensions of that service plugins are listed as supported
but none of them works. Resources are not extended (tag, revision,
auto-allocate) or some API extensions returns 404
(network-ip-availability or flavors).

What I proposed, is to improve all that service plugins of that list
to be able to support pluggable backend drivers (thanks to the Neutron
service driver mechanism [4]) and uses by default a driver based on
the Neutron DB(like it's implemented actually). That will permits core
plugin which not implements the Neutron DB model to provide its own
driver. But until all service plugins will be fixed, I proposed a
workaround to disable them.

[1] 
https://github.com/openstack/neutron/blob/master/neutron/neutron_plugin_base_v2.py#L30
[2] 
https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L124
[3] 
https://github.com/openstack/neutron/blob/master/neutron/services/timestamp/timestamp_plugin.py#L32
[4] 
https://github.com/openstack/neutron/blob/master/neutron/services/service_base.py#L27

Édouard.

On Thu, Jun 22, 2017 at 12:29 AM, Armando M.  wrote:
>
>
> On 21 June 2017 at 17:40, Édouard Thuleau  wrote:
>>
>> Hi,
>>
>> @Chaoyi,
>> I don't want to change the core plugin interface. But I'm not sure we
>> are talking about the same interface. I had a very quick look into the
>> tricycle code and I think it uses the NeutronDbPluginV2 interface [1]
>> which implements the Neutron DB model. Our Contrail Neutron plugin
>> implements the NeutronPluginBaseV2 interface [2]. Anyway,
>> NeutronDbPluginV2 is inheriting from NeutronPluginBaseV2 [3].
>> Thanks for the pointer to the stadium paragraph.
>
>
> Is there any bug report that captures the actual error you're facing? Out of
> the list of plugins that have been added to that list over time, most work
> just exercising the core plugin API, and we can look into the ones that
> don't to figure out whether we overlooked some design abstractions during
> code review.
>
>>
>>
>> @Kevin,
>> Service plugins loaded by default are defined in a contant list [4]
>> and I don't see how I can remove a default service plugin to be loaded
>> [5].
>>
>> [1]
>> https://github.com/openstack/tricircle/blob/master/tricircle/network/central_plugin.py#L128
>> [2]
>> https://github.com/Juniper/contrail-neutron-plugin/blob/master/neutron_plugin_contrail/plugins/opencontrail/contrail_plugin_base.py#L113
>> [3]
>> https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L125
>> [4]
>> https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43
>> [5]
>> https://github.com/openstack/neutron/blob/master/neutron/manager.py#L190
>>
>> Édouard.
>>
>> On Wed, Jun 21, 2017 at 11:22 AM, Kevin Benton  wrote:
>> > Why not just delete the service plugins you don't support from the
>> > default
>> > plugins dict?
>> >
>> > On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau
>> > 
>> > wrote:
>> >>
>> >> Ok, we would like to help on that. How we can start?
>> >>
>> >> I think the issue I raise in that thread must be the first point to
>> >> address and my second proposition seems to be the correct one. What do
>> >> you think?
>> >> But it will needs some time and not sure we'll be able to fix all
>> >> service plugins loaded by default before the next Pike release.
>> >>
>> >> I like to propose a workaround until all default service plugins will
>> >> be compatible with non-DB core plugins. We can continue to load that
>> >> default service plugins list but authorizing a core plugin to disable
>> >> it completely with a private attribut on the core plugin class like
>> >> it's done for bulk/pagination/sorting operations.
>> >>
>> >> Of course, we need to add the ability to report any regression on
>> >> that. I think unit tests will help and we can also work on a
>> >> functional test based on a fake non-DB core plugin.
>> >>
>> >> Regards,
>> >> Édouard.
>> >>
>> >> On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton 
>> >> wrote:
>> >> > The issue is mainly developer resources. Everyone currently working
>> >> > upstream
>> >> > doesn't have the bandwidth to keep adding/reviewing the layers of
>> >> > interfaces
>> >> > to make the DB optional that go untested. (None of the projects that
>> >> > would
>> >> > use them run a CI system that reports results on Neutron patches.)
>> >> >
>> >> > I think we can certainly accept patches to do the things you are
>> >> > proposing,
>> >> > but there is no guarantee that it won't regress to being DB-dependent
>> >> > 

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Armando M.]

On 21 June 2017 at 17:40, Édouard Thuleau  wrote:

> Hi,
>
> @Chaoyi,
> I don't want to change the core plugin interface. But I'm not sure we
> are talking about the same interface. I had a very quick look into the
> tricycle code and I think it uses the NeutronDbPluginV2 interface [1]
> which implements the Neutron DB model. Our Contrail Neutron plugin
> implements the NeutronPluginBaseV2 interface [2]. Anyway,
> NeutronDbPluginV2 is inheriting from NeutronPluginBaseV2 [3].
> Thanks for the pointer to the stadium paragraph.
>

Is there any bug report that captures the actual error you're facing? Out
of the list of plugins that have been added to that list over time, most
work just exercising the core plugin API, and we can look into the ones
that don't to figure out whether we overlooked some design abstractions
during code review.


>
> @Kevin,
> Service plugins loaded by default are defined in a contant list [4]
> and I don't see how I can remove a default service plugin to be loaded
> [5].
>
> [1] https://github.com/openstack/tricircle/blob/master/
> tricircle/network/central_plugin.py#L128
> [2] https://github.com/Juniper/contrail-neutron-plugin/blob/
> master/neutron_plugin_contrail/plugins/opencontrail/
> contrail_plugin_base.py#L113
> [3] https://github.com/openstack/neutron/blob/master/neutron/
> db/db_base_plugin_v2.py#L125
> [4] https://github.com/openstack/neutron/blob/master/neutron/
> plugins/common/constants.py#L43
> [5] https://github.com/openstack/neutron/blob/master/neutron/
> manager.py#L190
>
> Édouard.
>
> On Wed, Jun 21, 2017 at 11:22 AM, Kevin Benton  wrote:
> > Why not just delete the service plugins you don't support from the
> default
> > plugins dict?
> >
> > On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau <
> edouard.thul...@gmail.com>
> > wrote:
> >>
> >> Ok, we would like to help on that. How we can start?
> >>
> >> I think the issue I raise in that thread must be the first point to
> >> address and my second proposition seems to be the correct one. What do
> >> you think?
> >> But it will needs some time and not sure we'll be able to fix all
> >> service plugins loaded by default before the next Pike release.
> >>
> >> I like to propose a workaround until all default service plugins will
> >> be compatible with non-DB core plugins. We can continue to load that
> >> default service plugins list but authorizing a core plugin to disable
> >> it completely with a private attribut on the core plugin class like
> >> it's done for bulk/pagination/sorting operations.
> >>
> >> Of course, we need to add the ability to report any regression on
> >> that. I think unit tests will help and we can also work on a
> >> functional test based on a fake non-DB core plugin.
> >>
> >> Regards,
> >> Édouard.
> >>
> >> On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton 
> wrote:
> >> > The issue is mainly developer resources. Everyone currently working
> >> > upstream
> >> > doesn't have the bandwidth to keep adding/reviewing the layers of
> >> > interfaces
> >> > to make the DB optional that go untested. (None of the projects that
> >> > would
> >> > use them run a CI system that reports results on Neutron patches.)
> >> >
> >> > I think we can certainly accept patches to do the things you are
> >> > proposing,
> >> > but there is no guarantee that it won't regress to being DB-dependent
> >> > until
> >> > there is something reporting results back telling us when it breaks.
> >> >
> >> > So it's not that the community is against non-DB core plugins, it's
> just
> >> > that the people developing those plugins don't participate in the
> >> > community
> >> > to ensure they work.
> >> >
> >> > Cheers
> >> >
> >> >
> >> > On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau
> >> > 
> >> > wrote:
> >> >>
> >> >> Oops, sent too fast, sorry. I try again.
> >> >>
> >> >> Hi,
> >> >>
> >> >> Since Mitaka release, a default service plugins list is loaded when
> >> >> Neutron
> >> >> server starts [1]. That list is not editable and was extended with
> few
> >> >> services
> >> >> [2]. But all of them rely on the Neutron DB model.
> >> >>
> >> >> If a core driver is not based on the ML2 core plugin framework or not
> >> >> based on
> >> >> the 'neutron.db.models_v2' class, all that service plugins will not
> >> >> work.
> >> >>
> >> >> So my first question is Does Neutron still support core plugin not
> >> >> based
> >> >> on ML2
> >> >> or 'neutron.db.models_v2' class?
> >> >>
> >> >> If yes, I would like to propose two solutions:
> >> >> - permits core plugin to overload the service plugin class by it's
> own
> >> >> implementation and continuing to use the actual Neutron db based
> >> >> services
> >> >> as
> >> >> default.
> >> >> - modifying all default plugin service to use service plugin driver
> >> >> framework [3], and set the actual Neutron db based implementation as
> >> >> default driver for services. That permits 

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Armando M.]

On 20 June 2017 at 00:09, Kevin Benton  wrote:

> The issue is mainly developer resources. Everyone currently working
> upstream doesn't have the bandwidth to keep adding/reviewing the layers of
> interfaces to make the DB optional that go untested. (None of the projects
> that would use them run a CI system that reports results on Neutron
> patches.)
>
> I think we can certainly accept patches to do the things you are
> proposing, but there is no guarantee that it won't regress to being
> DB-dependent until there is something reporting results back telling us
> when it breaks.
>
> So it's not that the community is against non-DB core plugins, it's just
> that the people developing those plugins don't participate in the community
> to ensure they work.
>
> Cheers
>

> On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau <
> edouard.thul...@gmail.com> wrote:
>
>> Oops, sent too fast, sorry. I try again.
>>
>> Hi,
>>
>> Since Mitaka release, a default service plugins list is loaded when
>> Neutron
>> server starts [1]. That list is not editable and was extended with few
>> services
>> [2]. But all of them rely on the Neutron DB model.
>>
>> If a core driver is not based on the ML2 core plugin framework or not
>> based on
>> the 'neutron.db.models_v2' class, all that service plugins will not work.
>>
>
>
>> So my first question is Does Neutron still support core plugin not based
>> on ML2
>> or 'neutron.db.models_v2' class?
>>
>> If yes, I would like to propose two solutions:
>> - permits core plugin to overload the service plugin class by it's own
>> implementation and continuing to use the actual Neutron db based services
>> as
>> default.
>> - modifying all default plugin service to use service plugin driver
>> framework [3], and set the actual Neutron db based implementation as
>> default driver for services. That permits to core drivers not based on the
>> Neutron DB to specify a driver. We can see that solution was adopted in
>> the
>> networking-bgpvpn project, where can find two abstract driver classes,
>> one for
>> core driver based on Neutron DB model [4] and one used by core driver not
>> based
>> on the DB [5] as the Contrail driver [6].
>>
>
I think we're missing the the fundamental premise behind the introduction
of this map, which is that the addition of plugins to this list is done
only on the basis of the fact that the plugin being added introduces
functionality that's orthogonal to core plugins, and as such should work
with any, and not depend on internals of the core plugin implementation.

If something does break, it should be treated as a bug, rather than
allowing overloading this, because that's goes against the main rationale
for it being hard-coded.


>
>> [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d
>> 85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
>> [2] https://github.com/openstack/neutron/blob/master/neutron/plu
>> gins/common/constants.py#L43
>> [3] https://github.com/openstack/neutron/blob/master/neutron/ser
>> vices/service_base.py#L27
>> [4] https://github.com/openstack/networking-bgpvpn/blob/master/n
>> etworking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226
>> [5] https://github.com/openstack/networking-bgpvpn/blob/master/n
>> etworking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23
>> [6] https://github.com/Juniper/contrail-neutron-plugin/blob/mast
>> er/neutron_plugin_contrail/plugins/opencontrail/networking_
>> bgpvpn/contrail.py#L36
>>
>> Regards,
>> Édouard.
>>
>> On Mon, Jun 19, 2017 at 10:47 AM, Édouard Thuleau
>>  wrote:
>> > Hi,
>> > Since Mitaka release [1], a default service plugins list is loaded
>> > when Neutron server starts. That list is not editable and was extended
>> > with few services [2]. But none of th
>> >
>> > [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d
>> 85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
>> > [2] https://github.com/openstack/neutron/blob/master/neutron/plu
>> gins/common/constants.py#L43
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Édouard Thuleau]

Hi,

@Chaoyi,
I don't want to change the core plugin interface. But I'm not sure we
are talking about the same interface. I had a very quick look into the
tricycle code and I think it uses the NeutronDbPluginV2 interface [1]
which implements the Neutron DB model. Our Contrail Neutron plugin
implements the NeutronPluginBaseV2 interface [2]. Anyway,
NeutronDbPluginV2 is inheriting from NeutronPluginBaseV2 [3].
Thanks for the pointer to the stadium paragraph.

@Kevin,
Service plugins loaded by default are defined in a contant list [4]
and I don't see how I can remove a default service plugin to be loaded
[5].

[1] 
https://github.com/openstack/tricircle/blob/master/tricircle/network/central_plugin.py#L128
[2] 
https://github.com/Juniper/contrail-neutron-plugin/blob/master/neutron_plugin_contrail/plugins/opencontrail/contrail_plugin_base.py#L113
[3] 
https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L125
[4] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43
[5] https://github.com/openstack/neutron/blob/master/neutron/manager.py#L190

Édouard.

On Wed, Jun 21, 2017 at 11:22 AM, Kevin Benton  wrote:
> Why not just delete the service plugins you don't support from the default
> plugins dict?
>
> On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau 
> wrote:
>>
>> Ok, we would like to help on that. How we can start?
>>
>> I think the issue I raise in that thread must be the first point to
>> address and my second proposition seems to be the correct one. What do
>> you think?
>> But it will needs some time and not sure we'll be able to fix all
>> service plugins loaded by default before the next Pike release.
>>
>> I like to propose a workaround until all default service plugins will
>> be compatible with non-DB core plugins. We can continue to load that
>> default service plugins list but authorizing a core plugin to disable
>> it completely with a private attribut on the core plugin class like
>> it's done for bulk/pagination/sorting operations.
>>
>> Of course, we need to add the ability to report any regression on
>> that. I think unit tests will help and we can also work on a
>> functional test based on a fake non-DB core plugin.
>>
>> Regards,
>> Édouard.
>>
>> On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton  wrote:
>> > The issue is mainly developer resources. Everyone currently working
>> > upstream
>> > doesn't have the bandwidth to keep adding/reviewing the layers of
>> > interfaces
>> > to make the DB optional that go untested. (None of the projects that
>> > would
>> > use them run a CI system that reports results on Neutron patches.)
>> >
>> > I think we can certainly accept patches to do the things you are
>> > proposing,
>> > but there is no guarantee that it won't regress to being DB-dependent
>> > until
>> > there is something reporting results back telling us when it breaks.
>> >
>> > So it's not that the community is against non-DB core plugins, it's just
>> > that the people developing those plugins don't participate in the
>> > community
>> > to ensure they work.
>> >
>> > Cheers
>> >
>> >
>> > On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau
>> > 
>> > wrote:
>> >>
>> >> Oops, sent too fast, sorry. I try again.
>> >>
>> >> Hi,
>> >>
>> >> Since Mitaka release, a default service plugins list is loaded when
>> >> Neutron
>> >> server starts [1]. That list is not editable and was extended with few
>> >> services
>> >> [2]. But all of them rely on the Neutron DB model.
>> >>
>> >> If a core driver is not based on the ML2 core plugin framework or not
>> >> based on
>> >> the 'neutron.db.models_v2' class, all that service plugins will not
>> >> work.
>> >>
>> >> So my first question is Does Neutron still support core plugin not
>> >> based
>> >> on ML2
>> >> or 'neutron.db.models_v2' class?
>> >>
>> >> If yes, I would like to propose two solutions:
>> >> - permits core plugin to overload the service plugin class by it's own
>> >> implementation and continuing to use the actual Neutron db based
>> >> services
>> >> as
>> >> default.
>> >> - modifying all default plugin service to use service plugin driver
>> >> framework [3], and set the actual Neutron db based implementation as
>> >> default driver for services. That permits to core drivers not based on
>> >> the
>> >> Neutron DB to specify a driver. We can see that solution was adopted in
>> >> the
>> >> networking-bgpvpn project, where can find two abstract driver classes,
>> >> one
>> >> for
>> >> core driver based on Neutron DB model [4] and one used by core driver
>> >> not
>> >> based
>> >> on the DB [5] as the Contrail driver [6].
>> >>
>> >> [1]
>> >>
>> >> https://github.com/openstack/neutron/commit/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
>> >> [2]
>> >>
>> >> https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Kevin Benton]

Why not just delete the service plugins you don't support from the default
plugins dict?

On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau 
wrote:

> Ok, we would like to help on that. How we can start?
>
> I think the issue I raise in that thread must be the first point to
> address and my second proposition seems to be the correct one. What do
> you think?
> But it will needs some time and not sure we'll be able to fix all
> service plugins loaded by default before the next Pike release.
>
> I like to propose a workaround until all default service plugins will
> be compatible with non-DB core plugins. We can continue to load that
> default service plugins list but authorizing a core plugin to disable
> it completely with a private attribut on the core plugin class like
> it's done for bulk/pagination/sorting operations.
>
> Of course, we need to add the ability to report any regression on
> that. I think unit tests will help and we can also work on a
> functional test based on a fake non-DB core plugin.
>
> Regards,
> Édouard.
>
> On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton  wrote:
> > The issue is mainly developer resources. Everyone currently working
> upstream
> > doesn't have the bandwidth to keep adding/reviewing the layers of
> interfaces
> > to make the DB optional that go untested. (None of the projects that
> would
> > use them run a CI system that reports results on Neutron patches.)
> >
> > I think we can certainly accept patches to do the things you are
> proposing,
> > but there is no guarantee that it won't regress to being DB-dependent
> until
> > there is something reporting results back telling us when it breaks.
> >
> > So it's not that the community is against non-DB core plugins, it's just
> > that the people developing those plugins don't participate in the
> community
> > to ensure they work.
> >
> > Cheers
> >
> >
> > On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau <
> edouard.thul...@gmail.com>
> > wrote:
> >>
> >> Oops, sent too fast, sorry. I try again.
> >>
> >> Hi,
> >>
> >> Since Mitaka release, a default service plugins list is loaded when
> >> Neutron
> >> server starts [1]. That list is not editable and was extended with few
> >> services
> >> [2]. But all of them rely on the Neutron DB model.
> >>
> >> If a core driver is not based on the ML2 core plugin framework or not
> >> based on
> >> the 'neutron.db.models_v2' class, all that service plugins will not
> work.
> >>
> >> So my first question is Does Neutron still support core plugin not based
> >> on ML2
> >> or 'neutron.db.models_v2' class?
> >>
> >> If yes, I would like to propose two solutions:
> >> - permits core plugin to overload the service plugin class by it's own
> >> implementation and continuing to use the actual Neutron db based
> services
> >> as
> >> default.
> >> - modifying all default plugin service to use service plugin driver
> >> framework [3], and set the actual Neutron db based implementation as
> >> default driver for services. That permits to core drivers not based on
> the
> >> Neutron DB to specify a driver. We can see that solution was adopted in
> >> the
> >> networking-bgpvpn project, where can find two abstract driver classes,
> one
> >> for
> >> core driver based on Neutron DB model [4] and one used by core driver
> not
> >> based
> >> on the DB [5] as the Contrail driver [6].
> >>
> >> [1]
> >> https://github.com/openstack/neutron/commit/
> aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-
> 9169a6595980d19b2649d5bedfff05ce
> >> [2]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> plugins/common/constants.py#L43
> >> [3]
> >> https://github.com/openstack/neutron/blob/master/neutron/
> services/service_base.py#L27
> >> [4]
> >> https://github.com/openstack/networking-bgpvpn/blob/master/
> networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226
> >> [5]
> >> https://github.com/openstack/networking-bgpvpn/blob/master/
> networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23
> >> [6]
> >> https://github.com/Juniper/contrail-neutron-plugin/blob/
> master/neutron_plugin_contrail/plugins/opencontrail/
> networking_bgpvpn/contrail.py#L36
> >>
> >> Regards,
> >> Édouard.
> >>
> >> On Mon, Jun 19, 2017 at 10:47 AM, Édouard Thuleau
> >>  wrote:
> >> > Hi,
> >> > Since Mitaka release [1], a default service plugins list is loaded
> >> > when Neutron server starts. That list is not editable and was extended
> >> > with few services [2]. But none of th
> >> >
> >> > [1]
> >> > https://github.com/openstack/neutron/commit/
> aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-
> 9169a6595980d19b2649d5bedfff05ce
> >> > [2]
> >> > https://github.com/openstack/neutron/blob/master/neutron/
> plugins/common/constants.py#L43
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: 

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[joehuang]

Hi,

Tricricle is based on core plugin interface, so if you want to refactory the 
interface, let us know
whether it'll break Tricricle. And I don't know whether there other plugins are 
using
this interface.

And there is one conclusion in this 
document(https://github.com/openstack/neutron-specs/blob/master/specs/newton/neutron-stadium.rst):

To provide composable networking solutions: the ML2/Service plugin framework 
was introduced many cycles ago to enable users with freedom of choice. Many 
solutions have switched to using ML2/Service plugins for high level services 
over the years. Although some plugins still use the core plugin interface to 
provide end-to-end solutions, the criterion to enforce the adoption of ML2 and 
service plugins for Neutron Stadium projects does not invalidate, nor does make 
monolithic solutions deprecated. It is simply a reflection of the fact that the 
Neutron team stands behind composability as one of the promise of open 
networking solutions. During code review the Neutron team will continue to 
ensure that changes and design implications do not have a negative impact on 
out of tree code irrespective of whether it is part of the Stadium project or 
not.

Best Regards
Chaoyi Huang (joehuang)


From: Édouard Thuleau [edouard.thul...@gmail.com]
Sent: 21 June 2017 16:45
To: OpenStack Development Mailing List (not for usage questions); 
ke...@benton.pub
Cc: Sachin Bansal
Subject: Re: [openstack-dev] [neutron] Do we still support core plugin not 
based on the ML2 framework?

Ok, we would like to help on that. How we can start?

I think the issue I raise in that thread must be the first point to
address and my second proposition seems to be the correct one. What do
you think?
But it will needs some time and not sure we'll be able to fix all
service plugins loaded by default before the next Pike release.

I like to propose a workaround until all default service plugins will
be compatible with non-DB core plugins. We can continue to load that
default service plugins list but authorizing a core plugin to disable
it completely with a private attribut on the core plugin class like
it's done for bulk/pagination/sorting operations.

Of course, we need to add the ability to report any regression on
that. I think unit tests will help and we can also work on a
functional test based on a fake non-DB core plugin.

Regards,
Édouard.

On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton <ke...@benton.pub> wrote:
> The issue is mainly developer resources. Everyone currently working upstream
> doesn't have the bandwidth to keep adding/reviewing the layers of interfaces
> to make the DB optional that go untested. (None of the projects that would
> use them run a CI system that reports results on Neutron patches.)
>
> I think we can certainly accept patches to do the things you are proposing,
> but there is no guarantee that it won't regress to being DB-dependent until
> there is something reporting results back telling us when it breaks.
>
> So it's not that the community is against non-DB core plugins, it's just
> that the people developing those plugins don't participate in the community
> to ensure they work.
>
> Cheers
>
>
> On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau <edouard.thul...@gmail.com>
> wrote:
>>
>> Oops, sent too fast, sorry. I try again.
>>
>> Hi,
>>
>> Since Mitaka release, a default service plugins list is loaded when
>> Neutron
>> server starts [1]. That list is not editable and was extended with few
>> services
>> [2]. But all of them rely on the Neutron DB model.
>>
>> If a core driver is not based on the ML2 core plugin framework or not
>> based on
>> the 'neutron.db.models_v2' class, all that service plugins will not work.
>>
>> So my first question is Does Neutron still support core plugin not based
>> on ML2
>> or 'neutron.db.models_v2' class?
>>
>> If yes, I would like to propose two solutions:
>> - permits core plugin to overload the service plugin class by it's own
>> implementation and continuing to use the actual Neutron db based services
>> as
>> default.
>> - modifying all default plugin service to use service plugin driver
>> framework [3], and set the actual Neutron db based implementation as
>> default driver for services. That permits to core drivers not based on the
>> Neutron DB to specify a driver. We can see that solution was adopted in
>> the
>> networking-bgpvpn project, where can find two abstract driver classes, one
>> for
>> core driver based on Neutron DB model [4] and one used by core driver not
>> based
>> on the DB [5] as the Contrail driver [6].
>>
>> [1]
>> https://github.com/openstack/neutron/commit/aadf2f30f84dff

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Édouard Thuleau]

Ok, we would like to help on that. How we can start?

I think the issue I raise in that thread must be the first point to
address and my second proposition seems to be the correct one. What do
you think?
But it will needs some time and not sure we'll be able to fix all
service plugins loaded by default before the next Pike release.

I like to propose a workaround until all default service plugins will
be compatible with non-DB core plugins. We can continue to load that
default service plugins list but authorizing a core plugin to disable
it completely with a private attribut on the core plugin class like
it's done for bulk/pagination/sorting operations.

Of course, we need to add the ability to report any regression on
that. I think unit tests will help and we can also work on a
functional test based on a fake non-DB core plugin.

Regards,
Édouard.

On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton  wrote:
> The issue is mainly developer resources. Everyone currently working upstream
> doesn't have the bandwidth to keep adding/reviewing the layers of interfaces
> to make the DB optional that go untested. (None of the projects that would
> use them run a CI system that reports results on Neutron patches.)
>
> I think we can certainly accept patches to do the things you are proposing,
> but there is no guarantee that it won't regress to being DB-dependent until
> there is something reporting results back telling us when it breaks.
>
> So it's not that the community is against non-DB core plugins, it's just
> that the people developing those plugins don't participate in the community
> to ensure they work.
>
> Cheers
>
>
> On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau 
> wrote:
>>
>> Oops, sent too fast, sorry. I try again.
>>
>> Hi,
>>
>> Since Mitaka release, a default service plugins list is loaded when
>> Neutron
>> server starts [1]. That list is not editable and was extended with few
>> services
>> [2]. But all of them rely on the Neutron DB model.
>>
>> If a core driver is not based on the ML2 core plugin framework or not
>> based on
>> the 'neutron.db.models_v2' class, all that service plugins will not work.
>>
>> So my first question is Does Neutron still support core plugin not based
>> on ML2
>> or 'neutron.db.models_v2' class?
>>
>> If yes, I would like to propose two solutions:
>> - permits core plugin to overload the service plugin class by it's own
>> implementation and continuing to use the actual Neutron db based services
>> as
>> default.
>> - modifying all default plugin service to use service plugin driver
>> framework [3], and set the actual Neutron db based implementation as
>> default driver for services. That permits to core drivers not based on the
>> Neutron DB to specify a driver. We can see that solution was adopted in
>> the
>> networking-bgpvpn project, where can find two abstract driver classes, one
>> for
>> core driver based on Neutron DB model [4] and one used by core driver not
>> based
>> on the DB [5] as the Contrail driver [6].
>>
>> [1]
>> https://github.com/openstack/neutron/commit/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
>> [2]
>> https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43
>> [3]
>> https://github.com/openstack/neutron/blob/master/neutron/services/service_base.py#L27
>> [4]
>> https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226
>> [5]
>> https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23
>> [6]
>> https://github.com/Juniper/contrail-neutron-plugin/blob/master/neutron_plugin_contrail/plugins/opencontrail/networking_bgpvpn/contrail.py#L36
>>
>> Regards,
>> Édouard.
>>
>> On Mon, Jun 19, 2017 at 10:47 AM, Édouard Thuleau
>>  wrote:
>> > Hi,
>> > Since Mitaka release [1], a default service plugins list is loaded
>> > when Neutron server starts. That list is not editable and was extended
>> > with few services [2]. But none of th
>> >
>> > [1]
>> > https://github.com/openstack/neutron/commit/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
>> > [2]
>> > https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Kevin Benton]

The issue is mainly developer resources. Everyone currently working
upstream doesn't have the bandwidth to keep adding/reviewing the layers of
interfaces to make the DB optional that go untested. (None of the projects
that would use them run a CI system that reports results on Neutron
patches.)

I think we can certainly accept patches to do the things you are proposing,
but there is no guarantee that it won't regress to being DB-dependent until
there is something reporting results back telling us when it breaks.

So it's not that the community is against non-DB core plugins, it's just
that the people developing those plugins don't participate in the community
to ensure they work.

Cheers


On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau 
wrote:

> Oops, sent too fast, sorry. I try again.
>
> Hi,
>
> Since Mitaka release, a default service plugins list is loaded when Neutron
> server starts [1]. That list is not editable and was extended with few
> services
> [2]. But all of them rely on the Neutron DB model.
>
> If a core driver is not based on the ML2 core plugin framework or not
> based on
> the 'neutron.db.models_v2' class, all that service plugins will not work.
>
> So my first question is Does Neutron still support core plugin not based
> on ML2
> or 'neutron.db.models_v2' class?
>
> If yes, I would like to propose two solutions:
> - permits core plugin to overload the service plugin class by it's own
> implementation and continuing to use the actual Neutron db based services
> as
> default.
> - modifying all default plugin service to use service plugin driver
> framework [3], and set the actual Neutron db based implementation as
> default driver for services. That permits to core drivers not based on the
> Neutron DB to specify a driver. We can see that solution was adopted in the
> networking-bgpvpn project, where can find two abstract driver classes, one
> for
> core driver based on Neutron DB model [4] and one used by core driver not
> based
> on the DB [5] as the Contrail driver [6].
>
> [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d
> 85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
> [2] https://github.com/openstack/neutron/blob/master/neutron/plu
> gins/common/constants.py#L43
> [3] https://github.com/openstack/neutron/blob/master/neutron/ser
> vices/service_base.py#L27
> [4] https://github.com/openstack/networking-bgpvpn/blob/master/n
> etworking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226
> [5] https://github.com/openstack/networking-bgpvpn/blob/master/n
> etworking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23
> [6] https://github.com/Juniper/contrail-neutron-plugin/blob/mast
> er/neutron_plugin_contrail/plugins/opencontrail/networkin
> g_bgpvpn/contrail.py#L36
>
> Regards,
> Édouard.
>
> On Mon, Jun 19, 2017 at 10:47 AM, Édouard Thuleau
>  wrote:
> > Hi,
> > Since Mitaka release [1], a default service plugins list is loaded
> > when Neutron server starts. That list is not editable and was extended
> > with few services [2]. But none of th
> >
> > [1] https://github.com/openstack/neutron/commit/aadf2f30f84dff3d
> 85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
> > [2] https://github.com/openstack/neutron/blob/master/neutron/plu
> gins/common/constants.py#L43
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Do we still support core plugin not based on the ML2 framework?

[Édouard Thuleau]

Oops, sent too fast, sorry. I try again.

Hi,

Since Mitaka release, a default service plugins list is loaded when Neutron
server starts [1]. That list is not editable and was extended with few services
[2]. But all of them rely on the Neutron DB model.

If a core driver is not based on the ML2 core plugin framework or not based on
the 'neutron.db.models_v2' class, all that service plugins will not work.

So my first question is Does Neutron still support core plugin not based on ML2
or 'neutron.db.models_v2' class?

If yes, I would like to propose two solutions:
- permits core plugin to overload the service plugin class by it's own
implementation and continuing to use the actual Neutron db based services as
default.
- modifying all default plugin service to use service plugin driver
framework [3], and set the actual Neutron db based implementation as
default driver for services. That permits to core drivers not based on the
Neutron DB to specify a driver. We can see that solution was adopted in the
networking-bgpvpn project, where can find two abstract driver classes, one for
core driver based on Neutron DB model [4] and one used by core driver not based
on the DB [5] as the Contrail driver [6].

[1] 
https://github.com/openstack/neutron/commit/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
[2] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43
[3] 
https://github.com/openstack/neutron/blob/master/neutron/services/service_base.py#L27
[4] 
https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226
[5] 
https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23
[6] 
https://github.com/Juniper/contrail-neutron-plugin/blob/master/neutron_plugin_contrail/plugins/opencontrail/networking_bgpvpn/contrail.py#L36

Regards,
Édouard.

On Mon, Jun 19, 2017 at 10:47 AM, Édouard Thuleau
 wrote:
> Hi,
> Since Mitaka release [1], a default service plugins list is loaded
> when Neutron server starts. That list is not editable and was extended
> with few services [2]. But none of th
>
> [1] 
> https://github.com/openstack/neutron/commit/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce
> [2] 
> https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev