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. <arma...@gmail.com> wrote: > > > On 22 June 2017 at 17:24, Édouard Thuleau <edouard.thul...@gmail.com> 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. <arma...@gmail.com> wrote: >> > >> > >> > On 21 June 2017 at 17:40, Édouard Thuleau <edouard.thul...@gmail.com> >> > 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 <ke...@benton.pub> >> >> 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 <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/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 >> >> >> >> <edouard.thul...@gmail.com> 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 >> >> >> > >> >> > >> >> > >> >> >> >> >> >> __________________________________________________________________________ >> >> 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 >> > >> >> __________________________________________________________________________ >> 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 > __________________________________________________________________________ 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
