Server with ML2 & L3 service plugin exposes dvr extension even if OVS agent is unused

[Assaf Muller]

In a deployment using the L3 service plugin, the DVR extension is always declared as available, this is even if the ML2 OVS mech driver is not configured. Deployments could be using the LB mech driver or others. Not only is the extension declared, DVR router creation is not blocked. We should not rely only on documentation, but additionally provide expected behavior (Fail gracefully, not expose the extension).

[Swaminathan Vasudevan (swaminathan-vasudevan)]

Good point, is there a way that we can expose or not expose an extension based on the supported agents.

[Assaf Muller (amuller)]

I looked at this a while ago, and I'm not clear how to solve this. I was hoping someone else more knowledgeable of the extensions framework would know. The thing is is that the DVR extension is exposed by the L3 service plugin and not ML2. If it were exposed by ML2 (And I suppose it could be moved there), we could add the extension to the list via some conditionals (Is the L3 service plugin configured? Is the OVS mech driver configured?)

[Swaminathan Vasudevan (swaminathan-vasudevan)]

Yes there is no tie up between the L3 service and Ml2 plugin.

[Armando Migliaccio (armando-migliaccio)]

Technically speaking we could do as Assaf suggested on comment #2, but that makes my teeth grind a bit.

Having said that, I think this issue is really collateral damage, and there is a much, much larger problem at play here: what happens if another mech driver wants to support DVR, but in a fundamentally different way? We're stuck with a pervasive DVR logic within the plugin itself that makes certain architectural assumptions, like the presence of agents (L2 and L3). This makes the work incredibly difficult, if not virtually impossible.

I have been toying with some ideas in the context of the L2/L3 decoupling and the security groups support for agentless mech drivers, but oh boy that's hard!

I really don't see any value in addressing this particular issue (even though it could be considered a decent cosmetic stop-gap fix), but I'd rather nail the larger objective of moving aways from extensions in the context of [1], and trying to disentangle control from management plane in the context of [2].

[1] https://review.openstack.org/#/c/136760/
[2] https://review.openstack.org/#/c/176501/

[Swaminathan Vasudevan (swaminathan-vasudevan)]

I agree with you.

[Assaf Muller (amuller)]

I never understood the mindset of blocking short term work because of other planned long term work. They're not mutually exclusive in any way.

That being said, the 'opinion' status doesn't fit here. The bug exists from an operator's point of view, you just disagree about how to solve it.

[Armando Migliaccio (armando-migliaccio)]

I am not blocking anything here, you're free to push whatever fix you think it's worth pushing.

All I am saying is that is that the the issue itself exists beyond the L2/L3/DVR/OVS entanglement, and that the proposed way to fix it is only addressing a special case. The wording for 'opinion' is probably misleading here, but I chose it with the intention of soliciting discussion.

We have a long history of plastering Neutron with band aids...sure they'll work in the short term, and when no long-term fix follow up, what are we left with? I leave the answer to your imagination.

[Assaf Muller (amuller)]

As I said, I don't know how to fix this. I wanted to report a bug regardless so that it is tracked and searchable.

[Ihar Hrachyshka (ihar-hrachyshka)]

Side note: for QoS support, we expose rule_types API that reflect supported rule types and depends on what plugins report back, and for ml2, it's a common subset of all rule types supported by each of ml2 drivers: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/managers.py#n317

The fix for the bug could do something similar.

[Attila Fazekas (afazekas)]

dvr is also not working and reported as an available extension in l3 ha mode.
DVRmodeUpdateOfHaNotSupported

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/454203

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/454203
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=da8d5b4770fc86392e953de01b7250506c032500
Submitter: Jenkins
Branch: master

commit da8d5b4770fc86392e953de01b7250506c032500
Author: Ihar Hrachyshka <email address hidden>
Date: Thu Apr 6 14:03:15 2017 +0000

    Allow to disable DVR api extension loading

    A lot of clouds using the router service plugin don't configure for DVR,
    but the service plugin still loads the extension, and exposes it via
    API. Which will break if api consumers (admins with default policy.json)
    attempt to create new style routers based on the information passed
    through /extensions/ api.

    This change introduces a new config option that allows to avoid loading
    the extension. For complatibility sake, it requires an opt-in from ops
    side to disable it, otherwise the extension is still loaded as before.

    This is helpful for automation matters. It may also be useful when
    preparing tempest.conf api_extensions=, when you could actually pass the
    result of /extensions/ request into tempest and expect the test suite to
    pass without yanking dvr off the list for non-dvr setups.

    We could go further and try to check if the controller is configured
    properly. That is complicated by the fact that f.e. such validation may
    require talking to ml2 drivers, or even agents, which is not feasible
    during api startup.

    Change-Id: I84be9be93862fe71a2d5b5322d7ebd476c784163
    Related-Bug: #1450067

[Ihar Hrachyshka (ihar-hrachyshka)]

Now that we have a config knob for this, I believe we can claim it's fixed from neutron side. I understand there are some hard feelings about the solution, and we can revisit the way we tackle it later, but from short sight it seems like we can close the bug.