[neutron] Do we still support core plugin not based on the ML2 framework?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[neutron] Do we still support core plugin not based on the ML2 framework?

Édouard Thuleau-2
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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Édouard Thuleau-2
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
<[hidden email]> 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: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Kevin Benton-3
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 <[hidden email]> 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
<[hidden email]> 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-request@...enstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Édouard Thuleau-2
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 <[hidden email]> 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 <[hidden email]>
> 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
>> <[hidden email]> 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: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 [[hidden email]]
Sent: 21 June 2017 16:45
To: OpenStack Development Mailing List (not for usage questions); [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> 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
>> <[hidden email]> 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: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Kevin Benton-3
In reply to this post by Édouard Thuleau-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
>> <[hidden email]> 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-request@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-request@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Édouard Thuleau-2
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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
>> >> <[hidden email]> 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:
>> >> [hidden email]?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > [hidden email]?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Armando M.
In reply to this post by Kevin Benton-3


On 20 June 2017 at 00:09, Kevin Benton <[hidden email]> 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 <[hidden email]> 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/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
<[hidden email]> 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-request@...enstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Armando M.
In reply to this post by Édouard Thuleau-2


On 21 June 2017 at 17:40, Édouard Thuleau <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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
>> >> <[hidden email]> 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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Édouard Thuleau-2
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. <[hidden email]> wrote:

>
>
> On 21 June 2017 at 17:40, Édouard Thuleau <[hidden email]> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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
>> >> >> <[hidden email]> 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:
>> >> >> [hidden email]?subject:unsubscribe
>> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > __________________________________________________________________________
>> >> > OpenStack Development Mailing List (not for usage questions)
>> >> > Unsubscribe:
>> >> > [hidden email]?subject:unsubscribe
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >
>> >
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Armando M.


On 22 June 2017 at 17:24, Édouard Thuleau <[hidden email]> 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. <[hidden email]> wrote:
>
>
> On 21 June 2017 at 17:40, Édouard Thuleau <[hidden email]> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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
>> >> >> <[hidden email]> 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-request@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-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|

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

Édouard Thuleau-2
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. <[hidden email]> wrote:

>
>
> On 22 June 2017 at 17:24, Édouard Thuleau <[hidden email]> 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. <[hidden email]> wrote:
>> >
>> >
>> > On 21 June 2017 at 17:40, Édouard Thuleau <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]>
>> >> >> 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
>> >> >> > <[hidden email]>
>> >> >> > 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
>> >> >> >> <[hidden email]> 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:
>> >> >> >> [hidden email]?subject:unsubscribe
>> >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > __________________________________________________________________________
>> >> >> > OpenStack Development Mailing List (not for usage questions)
>> >> >> > Unsubscribe:
>> >> >> > [hidden email]?subject:unsubscribe
>> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >> __________________________________________________________________________
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe:
>> >> [hidden email]?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > [hidden email]?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: [hidden email]?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev