Open sp3c1k opened 2 months ago
Makes sense to me - we'd take a PR to change fix the Caracal gaps. @nelljerram WDYT in terms of approach (especially use of *args)?
All sounds good to me. For the avoidance of doubt, I believe we are only talking here about fixing up our coding to tolerate new args in some calls, and we are not talking about honouring the Neutron DB concept of segments in detail. IIRC segments were introduced as part of the idea of a Neutron network being partly routed - i.e. it has various L2 segments, with L3 routing between them. Calico has always been completely L3 routed - i.e. there is no L2 adjacency between workloads - and so it does not make sense for Calico to honour / implement the segment resource in detail.
Probably that was already well known to everyone here - but I thought I should say it just to make sure!
All sounds good to me. For the avoidance of doubt, I believe we are only talking here about fixing up our coding to tolerate new args in some calls, and we are not talking about honouring the Neutron DB concept of segments in detail.
We use Calico as core plugin for Neutron, therefore we depend entirely on the L3 networking Calico provides. I believe, at least for our use case, it should be sufficient to just support the new arguments that are passed to some calls by the new neutron code and not the whole concept of Neutron segments.
Hello,
after upgrading our Openstack to version 2024.1 (Caracal), we encountered some issues/errors regarding dhcp agent.
From what I have found, this seems to be due to: https://review.opendev.org/c/openstack/neutron/+/840421 (dhcp: support multiple segmentations per network) where they added
segment
arg here: https://github.com/openstack/neutron/blob/5f42221e3b5b9f7e0c391e7c9b88ca93a41914ec/neutron/agent/dhcp/agent.py#L263Networking_calico dhcp agent is currently not compatible with this change as it does not accept such argument.
We ad-hoc fixed it by adding
*args
to the__init__
method ofclass DnsmasqRouted(dhcp.Dnsmasq)
:We chose this approach as this should keep the compatibility with older Openstack versions (Zed and older). Simply adding
segment=None
would not work, as older Openstack versions does not support this variable inDhcpBase
class. https://github.com/openstack/neutron/blob/unmaintained/zed/neutron/agent/linux/dhcp.py#L183-L191Then a second problem appeared:
This seems to be related to:
From my understanding, it seems this change was made because when using neutron-dhcp-agent with ml2/ovn on ironic/baremetal nodes, ovn metadata route was not added correctly. Dhcp agent now uses
get_ports()
which is on the other side exposed by MetadataRpcCallback(server side) API. Since calico uses FakePlugin to support various calls that neutron.agent.linux.dhcp.Dnsmasq makes to what it thinks is Neutron database, I think it is necessary to addget_ports()
to FakePlugin.This is what we added and it seems to have resolved our problem:
I think it should be okay if it returns None, because:
If the DHCP interfaces we create does not end up in Neutron db to begin with, it should return None anyway.
Expected Behavior
Networking-calico and DHCP agent implementation should work with newer Openstack releases (2023.1 and newer)
Current Behavior
Current DHCP agent implementation seems to have problems with newer Openstack releases (2023.1 and newer)
Possible Solution
As written above, but it would be great if someone else confirmed these changes would make sense and would not break current behavior.
Steps to Reproduce (for bugs)
Context
This issue was encountered after upgrading Openstack to a newer version.
Your Environment