neutron service-provider-list return duplicated entries

[Yang Youseok]

After I add service_provider to neutron.conf with multiple service_provider enabled plugins, 'neutron service-provider-list' returned duplicated entries.

Here is neutron.conf snippet which makes problem and output of the command.

[DEFAULT]
service_plugins = l3_router,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

[service_providers]
service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default

openstack network service provider list
+----------------+-------------+---------+
| Service Type | Name | Default |
+----------------+-------------+---------+
| LOADBALANCERV2 | octavia | True |
| L3_ROUTER_NAT | single_node | False |
| L3_ROUTER_NAT | ha | False |
| L3_ROUTER_NAT | dvrha | False |
| L3_ROUTER_NAT | dvr | False |
| LOADBALANCERV2 | netscaler | False |
| LOADBALANCERV2 | octavia | True |
| LOADBALANCERV2 | netscaler | False |
+----------------+-------------+---------+

As you can see there were duplicated LOADBALANCERV2 typed providers. After digging the related code, there is no filtering logic in ProviderConfiguration class at all using service type (named svc_module in __init__()).

I think there should be filtering logic at ProviderConfiguration or NeutronModule class.

[Miguel Lavalle (minsel)]

Could this be a bug on the Octavia side in the way it sets up the service types? Command 'openstack network service provider list' is handled here: https://github.com/openstack/neutron/blob/master/neutron/db/servicetype_db.py#L55

[Yang Youseok (ileixe)]

@Miguel Lavalle
I don't think it's bug on Octavia side because Octavia actually have their own service provider normally. The problem is l3router have extra LOADABALCNERV2 service type provider which seems to be not reasonable.

I think the root cause is there is no way to filter service provider configuration using service type, so l3router can have extra service providers.

Here is related code. It just returned all service providers in config.
https://github.com/openstack/neutron/blob/master/neutron/services/provider_configuration.py#L109

I'm not sure having all service providers by all service plugin is intentional though, maybe it would be better to have only their own providers I think.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/561384

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/561384
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8ac92aa946a985a20d279312d041fd66e09a9fbd
Submitter: Zuul
Branch: master

commit 8ac92aa946a985a20d279312d041fd66e09a9fbd
Author: Yang Youseok <email address hidden>
Date: Thu Apr 19 16:26:40 2018 +0900

    Select service_provider on the basis of service_module

    In case of service_provider, selection according to service type is
    necessary. Currently there was no filtering logic, so if there are two
    or more service plugins using service_provider, there is a duplicate
    service_provider.

    New argument 'svc_type' is added to ProviderConfiguration so that only
    the service_provider matching the service type is shown.

    From caller side of ProviderConfiguration, one should specify
    'svc_type' since ProviderConfiguration class have new 'svc_type'
    argument to find service provider. Although netron code base using
    ProviderConfiguration changed, existed code out of newtron tree should
    be also modified following the change becuase if not, there would be
    duplicated entries problem currently appeared. But there is no
    difference without 'svc_type' argument because matching is effective
    only when the argument is specified.

    A new test case added in test_get_service_providers() in
    neutron/tests/unit/extensions/test_servicetype.py which does not
    have any filter options. Without this patch, this test case would be
    failed having duplicated results.

    Change-Id: I6ad9897dd174b45c7f2315699d25d38d4c060abc
    Closes-Bug: #1763627

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 14.0.0.0b1 development milestone.