Static IP Addresses from DHCP

In some OpenShift deployments, particularly Edge deployments, DHCP may not
always be available for various reasons. To allow these deployments to
function if they are not able to access the DHCP server, we have a request
to configure the address(es) received from DHCP as static IPs on the
deployed nodes. This would only be done if the lease received has an
infinite length, so there is a reasonable expectation that it won't be
reassigned.

enhancements/network/static-from-dhcp.md

@@ -0,0 +1,158 @@
+---
+title: static-ip-addresses-from-dhcp
+authors:
+  - "@cybertron"
+reviewers:
+  - "@celebdor"
+  - "@bcrochet"
+  - "@yboaron"
+  - "@dcbw"
+  - "@knobunc"
+approvers:
+  - "@shardy"
+creation-date: 2020-10-28
+last-updated: 2021-02-04
+status: implemented
+---
+
+# Static IP Addresses from DHCP
+
+## Release Signoff Checklist
+
+- [X] Enhancement is `implementable`
+- [X] Design details are appropriately documented from clear requirements
+- [X] Test plan is defined
+- [X] Graduation criteria for dev preview, tech preview, GA
+- [X] User-facing documentation is created in [openshift-docs](https://github.com/openshift/openshift-docs/)
+
+## Summary
+
+In some OpenShift deployments, particularly Edge deployments, DHCP may not
+always be available for various reasons. To allow these deployments to
+function if they are not able to access the DHCP server, we have a request
+to configure the address(es) received from DHCP as static IPs on the
+deployed nodes. This would only be done if the lease received has an
+infinite length, so there is a reasonable expectation that it won't be
+reassigned.
+
+## Motivation
+
+There are two primary use cases being addressed by this:
+
+1. Deployers on baremetal don't want an outage of their DHCP server to cascade
+   into an outage of their OpenShift cluster.
+
+2. Edge deployments may not have access to a DHCP server due to the limited
+   capacity in those environments.
+
+### Goals
+
+A DHCP server will initially be required for deployment, but after that the
+cluster should function with or without the DHCP server.
+
+### Non-Goals
+
+Fully static deployments with no DHCP at any point. That will require
+significantly larger architectural changes.
+
+## Proposal
+
+When we receive a DHCP lease with an infinite expiration time, create a static
+configuration on the node that reflects the values provided by the DHCP server.
+
+### User Stories [optional]
+
+#### Story 1
+
+As the administrator of a baremetal cluster, I do not want a DHCP server outage
+to cascade into an outage of any other services.
+
+#### Story 2
+
+As the deployer of an Edge environment, my nodes may have limited or no
+connectivity back to a central DHCP server. This should not affect their
+functionality.
+
+### Implementation Details/Notes/Constraints [optional]
+
+We will add a NetworkManager dispatcher script that looks at each DHCP lease.
+If the lease duration is infinite, the script will take the values provided
+through DHCP and configure them statically on the node using nmcli. This
+means the interface will not be configured via DHCP from then on, but since
+we don't allow changing IPs on nodes anyway that shouldn't be a problem.
+
+### Risks and Mitigations
+
+If an address that was statically assigned in this way is reassigned by the
+DHCP server, it could cause a conflict. There are two mitigations to this:
+First, the requirement for the lease time to be infinite makes it unlikely
+the server would reassign it in the course of normal operation, and second,
+some DHCP servers have conflict detection that will prevent them from
+reassigning an address that is active on the network.
+
+Static configuration of the node's networking may make future changes more
+difficult. In general we don't support changing the IP address of a node
+so that isn't a concern at this time, but if routes or DNS search domains
+are provided by DHCP it won't be possible to update those either after
+initial deployment. Making such changes after deployment would require use
+of a different mechanism.
+
+There may be deployers who do not want their DHCP addresses configured
+statically, but do want to use infinite DHCP leases. This could be worked
+around by using extremely long leases that are not technically infinite,
+but in practice would never expire.
+
+## Design Details
+
+### Open Questions
+
+### Test Plan
+
+This can be tested in virt environments by configuring the libvirt dnsmasq
+to provide infinite DHCP leases. Doing this directly with libvirt requires
+libvirt 6.3.0 or higher, which is not currently available in the CentOS 8
+hosts we use for CI. However, it is also possible to set the leases to
+infinite using a script that would live in dev-scripts, so we can still
+test this even with an older version of libvirt.
+
+To avoid adding an entire separate job to test this feature, we can instead
+apply the infinite leases to only a subset of the cluster nodes. This way
+both code paths will be tested in a single job.
+
+### Graduation Criteria
+
+This will be supported immediately.
+
+### Upgrade / Downgrade Strategy
+
+This behavior would largely have an effect at deployment time. For clusters
+with existing DHCP addresses that are not infinite leases there will be no
+change. A cluster with infinite DHCP leases would get them configured
+statically on upgrade. After that the addresses would be static unless
+the deployer made a change to the system configuration. If a cluster is
+using infinite DHCP leases and does *not* want them to be statically
+configured, the leases would need to be changed as discussed above.
+
+On downgrade, the behavior would remain the same. If the nodes were using
+DHCP before the downgrade, they will continue to. If they had been statically
+configured, that will also be persistent.
+
+### Version Skew Strategy
+
+Version skew should not be a problem. If some nodes are configured with DHCP and
+some with static addresses the end result should be the same. If it is not, that
+is a bug to be fixed.
+
+## Implementation History
+
+Implemented in 4.7.
+
+## Drawbacks
+
+See the risks and mitigations section above. It addresses the concerns I am
+aware of.
+
+## Alternatives
+
+In IPv6 deployments, SLAAC addressing could be used instead of DHCPv6 to provide
+stable addresses without the need for a DHCP server.