Files

Lucas Alvares Gomes e73a85f3dd [OVN] Add baremetal support without Neutron DHCP agent for IPv4

This patch adds support for deploying baremetal nodes with OVN's
built-in DHCP server for IPv4.

Since Neutron API's for setting DHCP options is mostly a pass-thru,
Ironic uses a dnsmasq syntax for setting the baremetal options [0].
Since this syntax is unlikely to change and it's only a tiny subset of
what dnsmasq can offer this patch does translate that syntax used by
Ironic and convert it to OVN's equivalent options. In this way we do not
need to re-design Neutron's DHCP options API nor change Ironic to use it
with ML2/OVN.

This option also adds a new configuration option called
"disable_ovn_dhcp_for_baremetal_ports". PXE booting nodes can be very
sensitive and operators may prefer to use a fully-fledged DHCP server to
do it (even Ironic makes DHCP pluggable). So if operators wish to
disable OVN's built-in DHCP server for baremetal provisioning they can
do so by setting this new option to True. It defaults to False.

This change has been tested with real hardware and it does work. That
said, we found a problem in core OVN itself [1] while testing it that
can affect PXE from reaching the TFTP server, we already communicated
this with the core OVN folks and we hope it can be fixed soon. The
change in core OVN should not affect the Neutron change tho.

Not that the "server-ip-address" DHCP Option now points to the
"next_server" option in OVN instead of the "tftp_server_address". The
previous behavior was wrong, the "server-ip-address" should set the
"siaddr" in the DHCP header and this has been introduced in OVN [2] as
an option called "next_server".

[0]
49113385e8/ironic/common/pxe_utils.py (L523-L538)
[1]
https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051821.html
[2]
https://patchwork.ozlabs.org/project/ovn/patch/20220511142757.168196-1-lmartins@redhat.com/

Partial-Bug: #1971431
Change-Id: Ia041f640293ba26abf9f70af915817e9861e8ffc
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>

2022-05-25 10:14:46 +01:00

3.2 KiB

Raw Blame History

Gaps from ML2/OVS

This is a list of some of the currently known gaps between ML2/OVS and OVN. It is not a complete list, but is enough to be used as a starting point for implementors working on closing these gaps. A TODO list for OVN is located at¹.

QoS Minimum Bandwidth support

Currently ML2/OVS supports QoS Minimum Bandwidth limiting, but it is not supported in OVN. The work on this is in progress. Details can be found at² and³.
BGP support

Neutron-dynamic-routing supports making a tenant subnet routable via BGP, and can announce host routes for both floating and fixed IP addresses. These functions are not supported in OVN.
Baremetal provisioning with iPXE without Neutron DHCP agent for IPv6

The core OVN built-in DHCP server implementation does not yet support PXE booting for IPv6. This can be achieved at the moment if used with the Neutron DHCP agent by deploying it on OVN gateway nodes and disabling the OVN DHCP by setting the [ovn]/disable_ovn_dhcp_for_baremetal_ports configuration option to True.
QoS minimum bandwidth allocation in Placement API

ML2/OVN integration with the Nova placement API to provide guaranteed minimum bandwidth for ports⁴. Work in progress, see⁵
IPv6 Prefix Delegation

Currently ML2/OVN doesn't implement IPv6 prefix delegation. OVN logical routers have this capability implemented in⁶ and we have an open RFE to fill this gap⁷.
East/West Fragmentation

The core OVN implementation does not support east/west fragmentation. There is no known production use-case for this feature hence we don't even have an RFE open for it and it's not on the roadmap to be implemented.
DHCP service for instances

ML2/OVS adds packet filtering rules to every instance that allow DHCP queries from instances to reach the DHCP agent. For OVN this traffic has to be explicitly allowed by security group rules attached to the instance. Note that the default security group does allow all outgoing traffic, so this only becomes relevant when using custom security groups⁸. Proposed patch is⁹ but it needs to be revived and updated.
DNS resolution for instances

OVN cannot use the host's networking for DNS resolution, so Case 2b in¹⁰ can only be used when additional DHCP agents are deployed. For Case 2a a different configuration option has to be used in ml2_conf.ini:
```
[ovn]
dns_servers = 203.0.113.8, 198.51.100.53
```

3.2 KiB Raw Blame History

Gaps from ML2/OVS

References

3.2 KiB

Raw Blame History