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... 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#neutro... 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