On 22 June 2017 at 17:24, Édouard Thuleau <[email protected]> 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. <[email protected]> wrote: > > > > > > On 21 June 2017 at 17:40, Édouard Thuleau <[email protected]> > 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 <[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 > > > > > > > > ____________________________________________________________ > ______________ > > 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
