Open Stack

Hi Neutrinos,

I'm wondering if we have a use case for the following RFE:

https://bugs.launchpad.net/neutron/+bug/1818479
Decouple placement reporting service plugin from ML2

Very close to the Stein rc1 deadline we merged a change with a review
comment we agreed to tackle in a followup RFE - the one above. Here's
the original comment from Slawek:

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

I see why Slawek left the comment, the placement reporter service
plugin's dependency on ML2 does hurt my aestethic sense too. But now
starting to work out the details of the followup work I'm not sure if
we have a use case here. I would like to understand if we have a use
case or not, because the change we talked about would increase code
complexity. So it needs justification. If we don't have a use case we
better do nothing and leave the complexity as it is. But if we do have
a use case I'm still happy to work on that.

In short: What concrete problems does it mean if the placement
reporter service plugin depends on the ML2 core plugin? When
eliminating that dependency what use case(s) are we generalizing the
code for?

I see the following options:

1) There may be an agent reporting its resource information in a
different format - unlike ovs-agent and sriov-agent.

2) There may be an agentless mechanism driver needing to sync to Placement.

3) There may be a non-ML2 core plugin needing to sync to Placement.

For (1) we standardized the format included in the agent's
configurations attribute. An agent newly implementing support for
reporting resource information should only deviate from that format if
that format cannot express the resource information. Do we have an
agent like that?

The format is basically a 2-layer mapping from physnets to the list of
their backing physical devices (whatever that is for an agent:
bridges, sriov PFs, etc) and further mapping to the backing devices'
inventory numbers.

For the exact format please see this piece of the docs:
https://docs.openstack.org/neutron/stein/admin/config-qos-min-bw.html#neutron-openvswitch-agent-config

Case (2) may be a realistic use case, but I'm not much familiar with
agentless mechanism drivers.

IIUC some agentless mechanism drivers actually maintain fake agent
entries in the neutron db. Those drivers can utilize the current
service plugin via the fake agent entries as if they were real.

For really agentless mechanism drivers (not even fake agent records)
and for (3) I'm inclined to say: Don't load this placement reporter
service plugin but write your own.

To summarize on a high level: Slawek's original comment on the
implicit dependency detects a real design smell, but I don't see how
refactoring the service plugin to a driver architecture would improve
the situation. What could nicely make this plugin more generic is
subscribing to another interface: create/update_host_resources()
instead of create/update_agent() because agents today are an
implementation detail of the ML2 drivers. But the host (instead of an
agent) is an abstraction we never had in neutron.

What do you think?

Sorry for the long mail,
Bence
irc: rubasov