Open Stack

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. <armamig at gmail.com> wrote:
>
>
> 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
>
>
>
> __________________________________________________________________________
> 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
>