WIP baremetal ipv6 fixes#1375
Conversation
Adding ipv6.dhcp-duid=ll means we get a predictable client ID so that reservations can be made on the DHCP server (which is needed to provide the hostname via DHCP)
|
@hardys: No Bugzilla bug is referenced in the title of this pull request. DetailsIn 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: hardys The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@hardys: GitHub didn't allow me to request PR reviews from the following users: derekhiggins. Note that only openshift members and repo collaborators can review this PR, and authors cannot review their own PRs. DetailsIn 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. |
|
My main question is - is this something that's just convenient for testing? Or is it something we really see as required for real (non-libvirt) deployments? |
Good question, I think it's required for all deployments, because we expect the hostname to be provided via DHCP, and we also expect to have static reservations which implies a predictable client ID (at least for dnsmasq, I've not yet investigated other DHCP servers, but I do know there are customer requirements to enable this working with dnsmasq). @celebdor would you agree? I think at this point we expect ipv6 to be a stateful replacement for ipv4, and as such we need to have predictable IP reservations and thus a duid? It seems that typical ipv6 server environments are dual-stack, and in that case you can imagine the ipv4 DHCP would be used to provide this information (with a potentially more stateless setup for ipv6 with a non-predictable server IP and router advertisements?), but in this case we know we have to make this work in a single-stack environment, so that isn't possible. |
|
@hardys since this was a test PR and the ipv6 stuff is done - do you still need this PR open? |
|
/close |
WIP fixes for ipv6 deployments with IPI baremetal, this is currently a test branch based on release-4.3 as we're testing with a 4.3 based build, but when we've figured out the fixes needed I'll re-submit the changes to master.