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