RFE Decouple placement reporting service plugin from ML2

[Bence Romsics]

This RFE tracks an improvement to the placement reporter service plugin that was suggested just a few days before the Stein feature freeze, so instead of working on it right there, this is delayed to the Train cycle. The original code review comment:

https://review.openstack.org/#/c/580672/30/neutron/services/placement_report/plugin.py@187

The placement reporter service plugin as merged in Stein depends on ML2. The improvement idea is to decouple it, by a driver pattern as in the qos service plugin. We need to investigate the costs and benefits of this refactoring and if it's feasible implement it in Train.

[Miguel Lavalle (minsel)]

Above you say "We need to investigate the costs and benefits of this refactoring and if it's feasible implement it in Train". Is the result of that investigation going to be reported in this RFE. Or in other words, how do we know we are ready to discuss this in the drivers meeting

[Bence Romsics (bence-romsics)]

Yes, this is not ready for the drivers meeting yet. I hope to do that investigation very early in the Train cycle and report the results here.

[Bence Romsics (bence-romsics)]

When I started to work out the details I hit a bunch of questions which I did write up on the ML:

http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005121.html

I had a face to face discussion about this complex topic with Slawek at the Denver Summit with a preliminary agreement summarized here:

* Let's improve the detection of incompatible plugin combinations at neutron-server startup time. The placement reporter service plugin should verify the core plugin loaded is one it can work together with (I'll take this work).
* We see a theoretical option to make the placement reporter plugin more generic, but not knowing the next use case in proper detail (likely how to support agentless mechanism drivers) we don't see how to realize this now practically. Therefore we propose to postpone any work here until one better understands the next use case. In order to avoid premature generalization.

Slawek, please correct me if I missed or misunderstood something.

[Slawek Kaplonski (slaweq)]

@Bence: it is correct what You wrote in last comment :) Thx.

[Bence Romsics (bence-romsics)]

As agreed on the PTG [1]:

* bence-romsics works on the change to improve the detection of incompatible plugin combinations as a follow up to https://bugs.launchpad.net/neutron/+bug/1578989.
* Otherwise we don't want to generalize the service plugin on a hypothetical basis so this RFE is postponed until a concrete, specific use case is found.

[1] https://etherpad.openstack.org/p/openstack-networking-train-ptg (section 'Best practices for ML2 dependent service plugins' around line 422)

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/660687

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/660687
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d10ba94d36da7ad7eb6ac9339bcac81ab169b93e
Submitter: Zuul
Branch: master

commit d10ba94d36da7ad7eb6ac9339bcac81ab169b93e
Author: Bence Romsics <email address hidden>
Date: Wed May 22 13:01:17 2019 +0200

    Log when the placement service plugin is used wrongly

    Log explicitly when an invalid plugin combination is requested in the
    config.

    The placement service plugin cannot be used with non-ML2 core
    plugins. neutron-server already exits when misconfigured like that
    (when a plugin raises an uncaught exception in its __init__())
    so I didn't change anything about that. This change only adds a more
    explicit log message for this misconfiguration.

    Change-Id: Ida1a3188f8b3145cf270d280bf942b3950c0779c
    Related-Bug: #1578989
    Related-Bug: #1818479