<div dir="ltr">Why not just delete the service plugins you don't support from the default plugins dict? </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 1:45 AM, Édouard Thuleau <span dir="ltr"><<a href="mailto:edouard.thuleau@gmail.com" target="_blank">edouard.thuleau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, we would like to help on that. How we can start?<br>
<br>
I think the issue I raise in that thread must be the first point to<br>
address and my second proposition seems to be the correct one. What do<br>
you think?<br>
But it will needs some time and not sure we'll be able to fix all<br>
service plugins loaded by default before the next Pike release.<br>
<br>
I like to propose a workaround until all default service plugins will<br>
be compatible with non-DB core plugins. We can continue to load that<br>
default service plugins list but authorizing a core plugin to disable<br>
it completely with a private attribut on the core plugin class like<br>
it's done for bulk/pagination/sorting operations.<br>
<br>
Of course, we need to add the ability to report any regression on<br>
that. I think unit tests will help and we can also work on a<br>
functional test based on a fake non-DB core plugin.<br>
<br>
Regards,<br>
Édouard.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Jun 20, 2017 at 12:09 AM, Kevin Benton <kevin@benton.pub> wrote:<br>
> The issue is mainly developer resources. Everyone currently working upstream<br>
> doesn't have the bandwidth to keep adding/reviewing the layers of interfaces<br>
> to make the DB optional that go untested. (None of the projects that would<br>
> use them run a CI system that reports results on Neutron patches.)<br>
><br>
> I think we can certainly accept patches to do the things you are proposing,<br>
> but there is no guarantee that it won't regress to being DB-dependent until<br>
> there is something reporting results back telling us when it breaks.<br>
><br>
> So it's not that the community is against non-DB core plugins, it's just<br>
> that the people developing those plugins don't participate in the community<br>
> to ensure they work.<br>
><br>
> Cheers<br>
><br>
><br>
> On Mon, Jun 19, 2017 at 2:15 AM, Édouard Thuleau <<a href="mailto:edouard.thuleau@gmail.com">edouard.thuleau@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Oops, sent too fast, sorry. I try again.<br>
>><br>
>> Hi,<br>
>><br>
>> Since Mitaka release, a default service plugins list is loaded when<br>
>> Neutron<br>
>> server starts [1]. That list is not editable and was extended with few<br>
>> services<br>
>> [2]. But all of them rely on the Neutron DB model.<br>
>><br>
>> If a core driver is not based on the ML2 core plugin framework or not<br>
>> based on<br>
>> the 'neutron.db.models_v2' class, all that service plugins will not work.<br>
>><br>
>> So my first question is Does Neutron still support core plugin not based<br>
>> on ML2<br>
>> or 'neutron.db.models_v2' class?<br>
>><br>
>> If yes, I would like to propose two solutions:<br>
>> - permits core plugin to overload the service plugin class by it's own<br>
>> implementation and continuing to use the actual Neutron db based services<br>
>> as<br>
>> default.<br>
>> - modifying all default plugin service to use service plugin driver<br>
>> framework [3], and set the actual Neutron db based implementation as<br>
>> default driver for services. That permits to core drivers not based on the<br>
>> Neutron DB to specify a driver. We can see that solution was adopted in<br>
>> the<br>
>> networking-bgpvpn project, where can find two abstract driver classes, one<br>
>> for<br>
>> core driver based on Neutron DB model [4] and one used by core driver not<br>
>> based<br>
>> on the DB [5] as the Contrail driver [6].<br>
>><br>
>> [1]<br>
>> <a href="https://github.com/openstack/neutron/commit/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>neutron/commit/<wbr>aadf2f30f84dff3d85f380a7ff4e16<wbr>dbbb0c6bb0#diff-<wbr>9169a6595980d19b2649d5bedfff05<wbr>ce</a><br>
>> [2]<br>
>> <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>neutron/blob/master/neutron/<wbr>plugins/common/constants.py#<wbr>L43</a><br>
>> [3]<br>
>> <a href="https://github.com/openstack/neutron/blob/master/neutron/services/service_base.py#L27" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>neutron/blob/master/neutron/<wbr>services/service_base.py#L27</a><br>
>> [4]<br>
>> <a href="https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L226" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>networking-bgpvpn/blob/master/<wbr>networking_bgpvpn/neutron/<wbr>services/service_drivers/<wbr>driver_api.py#L226</a><br>
>> [5]<br>
>> <a href="https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/driver_api.py#L23" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>networking-bgpvpn/blob/master/<wbr>networking_bgpvpn/neutron/<wbr>services/service_drivers/<wbr>driver_api.py#L23</a><br>
>> [6]<br>
>> <a href="https://github.com/Juniper/contrail-neutron-plugin/blob/master/neutron_plugin_contrail/plugins/opencontrail/networking_bgpvpn/contrail.py#L36" rel="noreferrer" target="_blank">https://github.com/Juniper/<wbr>contrail-neutron-plugin/blob/<wbr>master/neutron_plugin_<wbr>contrail/plugins/opencontrail/<wbr>networking_bgpvpn/contrail.py#<wbr>L36</a><br>
>><br>
>> Regards,<br>
>> Édouard.<br>
>><br>
>> On Mon, Jun 19, 2017 at 10:47 AM, Édouard Thuleau<br>
>> <<a href="mailto:edouard.thuleau@gmail.com">edouard.thuleau@gmail.com</a>> wrote:<br>
>> > Hi,<br>
>> > Since Mitaka release [1], a default service plugins list is loaded<br>
>> > when Neutron server starts. That list is not editable and was extended<br>
>> > with few services [2]. But none of th<br>
>> ><br>
>> > [1]<br>
>> > <a href="https://github.com/openstack/neutron/commit/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0#diff-9169a6595980d19b2649d5bedfff05ce" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>neutron/commit/<wbr>aadf2f30f84dff3d85f380a7ff4e16<wbr>dbbb0c6bb0#diff-<wbr>9169a6595980d19b2649d5bedfff05<wbr>ce</a><br>
>> > [2]<br>
>> > <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/common/constants.py#L43" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>neutron/blob/master/neutron/<wbr>plugins/common/constants.py#<wbr>L43</a><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
</div></div></blockquote></div><br></div>