Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1841135

Summary:	Increase default provisioning DHCP range
Product:	OpenShift Container Platform	Reporter:	Dave Wilson <dwilson>
Component:	Bare Metal Hardware Provisioning	Assignee:	Beth White <beth.white>
Bare Metal Hardware Provisioning sub component:	cluster-api-provider	QA Contact:	Eldar Weiss <eweiss>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	low
Priority:	low	CC:	athomas, beth.white, dblack, pablo.iranzo, racedoro, stbenjam
Version:	4.4	Keywords:	Reopened, Triaged
Target Milestone:	---
Target Release:	4.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	The default DHCP range for the provisioning network was increased to include the remainder of the subnet to better support large deployments. The range is still configurable if users would like to use less of the subnet for DHCP.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-10-27 16:01:56 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:
Bug Depends On:
Bug Blocks:	1831748

Description Dave Wilson 2020-05-28 12:59:38 UTC

Description of problem: default provisioning DHCP range is too low for large scale BM deploys. Can we set it at .10 to $subnet_max instead of .10 to .100?


Version-Release number of selected component (if applicable): 4.4


How reproducible: 100%


Steps to Reproduce:
1. Deploy > 90 BM nodes


Actual results: Node will not get DHCP offer on pxe due to 90 max leases


Expected results: Node pxe's and provisions


Additional info:

Comment 3 Stephen Benjamin 2020-06-02 16:26:24 UTC

The DHCP range is configurable to be as large as a user likes. There's no limitation there. A user can set provisioningDHCPRange in the install-platform, so I think this is much lower priority than currently indicated.

In general we expect the provisioning subnet to be dedicated and owned by the cluster, so updating the default to be $SUBNET_MAX may be a reasonable thing to do. It needs a bit more discussion, but I think we can leave this open to have a look at it in the 4.6 cycle.

I do not think we should backport it, as it would be quite surprising if you're used to deploying 4.4 and made assumptions about the provisioning network that suddenly become untrue in a z-Stream.

Comment 6 Eldar Weiss 2020-07-15 15:09:07 UTC

Description of problem: default provisioning DHCP range is too low for large scale BM deploys. 

Version-Release number the fix was verified on: 4.6.0-0.nightly-2020-07-15-065024.

Steps to verify fix:
1. Run this on the provisionhost for both IPV4 and IPV6
oc get provisioning -o yaml | grep provisioningDHCPRange
2.
Actual results:
IPV4 example:
        f:provisioningDHCPRange: {}
        provisioningDHCPRange: 172.22.0.10,172.22.0.254
IPV6 example:
        f:provisioningDHCPRange: {}
        provisioningDHCPRange:     fd00:1101::a,fd00:1101::ffff:ffff:ffff:fffe 
Expected results: wide range for IP addresses, as seen above.
Additional info:

Comment 8 errata-xmlrpc 2020-10-27 16:01:56 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4196