Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

cybertron
Copy link
Member

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.

Copy link

@ori-amizur ori-amizur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Questions:

  1. Is this relevant to VIPs address assignment by DHCP, or just to node address assignment?
  2. 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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Questions:

  1. Is this relevant to VIPs address assignment by DHCP, or just to node address assignment?
  2. 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?

Copy link
Member Author

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.

@cybertron
Copy link
Member Author

/cc @dcbw @knobunc

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.
Copy link
Contributor

@hardys hardys Nov 16, 2020

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?

Copy link
Member Author

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.

Copy link
Member Author

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.

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign kbsingh after the PR has been reviewed.
You can assign the PR to them by writing /assign @kbsingh in a comment when ready.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

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.
@cybertron
Copy link
Member Author

@hardys I think this should be ready to go now. Let me know what you think.

@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 20, 2021
@openshift-bot
Copy link

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci openshift-ci bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jun 19, 2021
@openshift-bot
Copy link

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-ci openshift-ci bot closed this Jul 19, 2021
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jul 19, 2021

@openshift-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants