Bug 1880507

Summary: [RFE] dnsmasq provided IP addresses should be converted to static for optimum resilience
Product: OpenShift Container Platform Reporter: Chris Paquin <cpaquin>
Component: Bare Metal Hardware ProvisioningAssignee: Steven Hardy <shardy>
Bare Metal Hardware Provisioning sub component: baremetal-operator QA Contact: Amit Ugol <augol>
Status: CLOSED DEFERRED Docs Contact:
Severity: unspecified    
Priority: unspecified CC: asegurap, brad, jhuddles, racedoro
Version: unspecifiedKeywords: Triaged
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-24 13:57:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Chris Paquin 2020-09-18 17:25:16 UTC
Description of problem:

dnsmasq, running on bastion node, provides ip addresses to cluster nodes. Node IPs are assigned via dhcp, and have a lease with a configurable renewal. Even if an external dhcp provider is used (infoblox, or bind (HA)) there is still a requirement on the availability of dhcp services. This is of particular interest to those deploying to the edge, where local connectivity to dns services may not be guaranteed. 

Ask here is to configure baremetal installer to have option to configure dhcp assigned addresses as static.

Below is an example of baremetal.conf config for dnsmasq running on bastion node.
In this env, two interfaces form a bond. Once interface is singled out and assigned the IP address.  Bond is configured on host as part of the deployment process. 


# dhcp for baremetal network
no-dhcp-interface=lo
interface=baremetal
dhcp-range=set:baremetal,10.75.71.96,static,24h
dhcp-option=tag:baremetal,option:netmask,255.255.255.224
dhcp-option=tag:baremetal,option:router,10.75.71.97
dhcp-option=tag:baremetal,option:ntp-server,96.239.250.57
dhcp-option=tag:baremetal,option:dns-server,96.239.250.47

# Bootstrap
dhcp-host=52:54:00:*:*:*,10.75.71.107,set:baremetal

# Master nodes
dhcp-host=b8:59:9f:ec:9d:78,id:b8:59:9f:ec:9d:78,master-0,10.75.71.102,set:baremetal

Comment 1 Steven Hardy 2020-09-21 10:35:10 UTC
I'm not sure we want to add any interface that explicitly enables this, it seems like a workaround due to the limited OCP support for static IPs that exists today?

I think this approach is risky (any misconfiguration resulting in a missing reservation could result in an IP conflict), and probably the choice should be to either use DHCP or static IPs, but we know there is work ongoing to enable the latter but there are significant gaps (no way at present to specify per-node config via the MCO).

I know Toni and team have been looking at declarative network configuration (including support for static IPs, but only for secondary interfaces initially) - it seems like we should ensure we prioritize the more general requirement for static IPs in baremetal environments appropriately, which would avoid the need for this kind of workaround?

Comment 3 Brad P. Crochet 2020-09-22 16:38:33 UTC
Feature requests should be created in Jira, to be tracked and discussed there.

Comment 4 Chris Paquin 2020-09-22 17:43:40 UTC
(In reply to Steven Hardy from comment #1)
> I'm not sure we want to add any interface that explicitly enables this, it
> seems like a workaround due to the limited OCP support for static IPs that
> exists today?
> 
> I think this approach is risky (any misconfiguration resulting in a missing
> reservation could result in an IP conflict), and probably the choice should
> be to either use DHCP or static IPs, but we know there is work ongoing to
> enable the latter but there are significant gaps (no way at present to
> specify per-node config via the MCO).
> 
> I know Toni and team have been looking at declarative network configuration
> (including support for static IPs, but only for secondary interfaces
> initially) - it seems like we should ensure we prioritize the more general
> requirement for static IPs in baremetal environments appropriately, which
> would avoid the need for this kind of workaround?

So to clarify, I think that static IP addresses will be fine to meet the ask. Technically while we are using dnsmasq to assign DHCP addresses, the addresses are statically reserved anyway. I do see your point. If an ip address is assigned dynamically, and then moved to static, it must be moved out of the range of assignable ip addresses. 

Main concern from customer perspective is availability of dnsmasq and expiration of lease. dnsmasq is not HA solution, external dns provider is the best option. However, in the case of far-edge, dns services may not always be available.

Comment 5 Antoni Segura Puimedon 2020-09-23 18:38:46 UTC
Just to confirm, that's only about the control plane network, right?

Comment 6 Chris Paquin 2020-09-23 21:05:23 UTC
Baremetal, not control plane.

Comment 7 Steven Hardy 2020-09-24 13:57:50 UTC
(In reply to Chris Paquin from comment #4)
> (In reply to Steven Hardy from comment #1)
> > I'm not sure we want to add any interface that explicitly enables this, it
> > seems like a workaround due to the limited OCP support for static IPs that
> > exists today?
> > 
> > I think this approach is risky (any misconfiguration resulting in a missing
> > reservation could result in an IP conflict), and probably the choice should
> > be to either use DHCP or static IPs, but we know there is work ongoing to
> > enable the latter but there are significant gaps (no way at present to
> > specify per-node config via the MCO).
> > 
> > I know Toni and team have been looking at declarative network configuration
> > (including support for static IPs, but only for secondary interfaces
> > initially) - it seems like we should ensure we prioritize the more general
> > requirement for static IPs in baremetal environments appropriately, which
> > would avoid the need for this kind of workaround?
> 
> So to clarify, I think that static IP addresses will be fine to meet the
> ask. Technically while we are using dnsmasq to assign DHCP addresses, the
> addresses are statically reserved anyway. I do see your point. If an ip
> address is assigned dynamically, and then moved to static, it must be moved
> out of the range of assignable ip addresses. 

Ok thanks, so I think we should close this bz and track the requirement for static IPs as a core OpenShift enhancement - I'll take that up with PM.

> Main concern from customer perspective is availability of dnsmasq and
> expiration of lease. dnsmasq is not HA solution, external dns provider is
> the best option. However, in the case of far-edge, dns services may not
> always be available.

That's an implementation detail of the customer environment, which as you say probably means static IPs would be preferable, so as above we can track that as an RFE in Jira.

Comment 9 Red Hat Bugzilla 2023-09-14 06:08:37 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days