-
Notifications
You must be signed in to change notification settings - Fork 475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Static IP Addresses from DHCP #520
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Questions:
- Is this relevant to VIPs address assignment by DHCP, or just to node address assignment?
- In case of installation by assisted-installer, what is the suggestion to handle DHCP leases before and after the installation has started? Does it imply changes in assisted installer that performs DHCP VIP addresses allocation?
|
||
## Summary | ||
|
||
In some OpenShift deployments, particularly Edge deployments, DHCP may not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Questions:
- Is this relevant to VIPs address assignment by DHCP, or just to node address assignment?
- In case of installation by assisted-installer, what is the suggestion to handle DHCP leases before and after the installation has started? Does it imply changes in assisted installer that performs DHCP VIP addresses allocation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is largely separate from the DHCP VIPs. The only implications it might have is that we need to make sure if the VIPs were assigned by DHCP they handle losing access to the DHCP server. Probably that means making sure the lease file we use for dhclient is in a persistent location, if it isn't already.
Otherwise this doesn't change much in terms of installation. A DHCP server is still required for initial installation to provide the IPs in the first place.
This should be testable in virt environments. The one concern would be | ||
whether our dev environment configurations can be configured to use | ||
infinite leases. However, I believe our test team has a way to test with | ||
external DHCP, so that should allow us to do what we need. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to figure out where CI coverage for this can exist - maybe a new e2e-metal-ipi periodic job, or we could consider enabling this behavior in one of the existing jobs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a patch up to enable support for this in dev-scripts: openshift-metal3/dev-scripts#1176
One option to test this in the existing jobs would be to set just one node to have an infinite lease. That way we'd have coverage of both paths. The only issue with that is our current version of libvirt chokes on infinite leases, which causes errors in some of the post-deploy steps. The cluster deploys fine, but as Derek noted on the dev-scripts pr it prevents things like clouds.yaml from being generated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I have recently discovered that the centos 8 advanced-virtualization repo now has a new enough version of libvirt to test this properly without hacking the libvirt dnsmasq config. I've updated the enhancement to suggest a periodic job since testing this will require things like rebooting the nodes without a DHCP server, which doesn't make sense for most changes we test.
8665cc8
to
89d2991
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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.
89d2991
to
ed2dfab
Compare
@hardys I think this should be ready to go now. Let me know what you think. |
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
@openshift-bot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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.