Open Stack

On 22 June 2017 at 17:24, Édouard Thuleau <edouard.thuleau at 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. <armamig at gmail.com> wrote:
> >
> >
> > On 21 June 2017 at 17:40, Édouard Thuleau <edouard.thuleau at 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 <kevin at 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.thuleau at 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 <kevin at 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.thuleau at 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.thuleau at 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-request at 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 at 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 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170622/37cba213/attachment-0001.html>