-
Notifications
You must be signed in to change notification settings - Fork 113
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
Changes needed for IPv6 #107
Conversation
#108 is a possible alternative approach which avoids the new variable, wdyt? |
I liked the idea of being explicit that we want IPv6 so there’s no surprises. Could we have dual stack environments where the host could get IPv4 and 6 addresses? |
In the future yes, but I think we'll need further changes to enable that? I guess we could try to parse both IPs - @derekhiggins what are your thoughts here? |
At least initially I was worried if a nic gets both IPv4 and IPv6 addresses we don’t actually know which one we’ll pick. Maybe that’s not a concern but I’ve usually been in environments where you get both rather than just IPv6. |
Although for provisioning we have control so maybe I’m overthinking the problem. |
That is a valid concern, particularly if/when we lock down the service bind IPs to a specific interface/IP e.g #56 - in that case I don't think we can tell Ironic to listen on more than one protocol, only a wildcard or a specific IP? My main worry with adding an explicit interface here is that we then have to wire in that new value via the installer and MAO, e.g like openshift/installer#2449 and openshift/machine-api-operator#402 - if we were to consider only the single-stack case initially we can just fix the validation in the installer to allow ipv6 addresses, whereas for dual-stack the interface changes are much more invasive, e.g duplicate configuration for all-the-things. My vote is to detect the IP without any new flag, and to be safe we could make container startup fail if we detect more than one (non link-local) IP configured on the nic? |
Another option would be to wire in the PROVISIONING_IP (or the entire configmap) to all containers, then we wouldn't have to detect the IP, but the disadvantage there is we could have a race between the static-ip-manager container and those running the services? |
We could have the start scripts wait for that exact IP, though, instead of waiting anything on the interface. |
That's a good point, and I guess we could also minimise the interface changes if we started using envFrom to pass the entire configmap into all containers vs specific keys e.g https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables |
We could parse both IP's if present but I guess we need a way to decide which to use if both are present, on the bootstrap node I'm doing this by testing which gateway I can ping but finding someway to pass IPv4 or 6 to be explicit is probably better.
|
Ok so it sounds like the conclusion is to add an explicit PROVISIONING_IP interface, and if that exists it will override PROVISIONING_INTERFACE and wait for an interface to be up with that IP, at which point we then configure the service to use the specified IP. This keeps things explicit but also avoids adding any new interfaces to the openshift integration (we already require provisioning_ip for some other containers in the BMO pod), although it will require some adjustment to the sample ConfigMap in the BMO. |
I pushed some changes that reflect the discussion, what do you think? It prefers PROVISIONING_IP over _INTERFACE. I updated metal3-io/baremetal-operator#324 to use Both instances of httpd come up and are accessible over IPv6: [notstack@master-2 metal3-dev-env]$ curl -qs http://\[fd2e:6f44:5dd8:b856::1\]/inspector.ipxe 2>&1>/dev/null && echo "success!"
success!
[notstack@master-2 metal3-dev-env]$ curl -qs http://\[fd2e:6f44:5dd8:b856::2\]:6180/inspector.ipxe 2>&1>/dev/null && echo "success!"
success! I agree we should try to bring over the LOCAL_IMAGE stuff from dev-scripts instead of relying on my quay.io builds, I can look at that on Monday if no one else gets to it before then. |
Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/1260/ |
Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/1262/ |
Build SUCCESS, see build http://10.8.144.11:8080/job/dev-tools/1264/ |
Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/1298/ |
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.
Looks good, just one rebase issue, and a question about the kernel/ramdisk symlinks
@maelk FYI this looks nearly ready - if we push a WIP pr to metal3-dev-env with IRONIC_IMAGE_LOCAL_IMAGE set, will the integration tests pick that up, or does the ironic image always get baked into the pre-built minikube? |
This commit adds support for IPv6. When $PROVISIONING_IP is specified, which may be an IPv6 address, the various containers will wait for that IP to become available on an interface. If the IP is IPv6, then we use an IPv6-specific configurations. Note, IPv6 hosts are expected to be using UEFI boot, as we use snponly.efi. snponly.efi uses the UEFI network stack instead of the iPXE drivers. When using EDK2 OVMF + iPXE + ipxe.efi, we have seen lock-ups in initialization of the hardware devices. As neither CentOS nor RHEL distribute iPXE builds with IPv6 support, we build them from source as part of the container build.
Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/1299/ |
@hardys Can you update your review flag for this? It only has one approver so far and needs 2 plus the lgtm if it is ready. |
enable-ra | ||
ra-param=PROVISIONING_INTERFACE,10 | ||
|
||
dhcp-vendorclass=set:pxe6,enterprise:343,PXEClient |
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.
We sure this is right? I think we're doing does not offer and the arch matches logic in ironic. :\ I would be worried about enterprises differing across NICs
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'm not sure, is the concern that other vendors might not use this? I got this value from @derekhiggins initial investigations of getting IPv6 PXE working. There's a note here https://dox.ipxe.org/dhcpv6_8h.html#a24258ff3db7cdd24d6084d5950c87852:
00151 /** DHCPv6 PXE vendor class
00152 *
00153 * The DHCPv6 vendor class includes a field for an IANA enterprise
00154 * number. The EDK2 codebase uses the value 343, with the comment:
00155 *
00156 * TODO: IANA TBD: temporarily using Intel's
00157 *
00158 * Since this "temporarily" has applied since at least 2010, we assume
00159 * that it has become a de facto standard.
00160 */
00161 #define DHCPV6_VENDOR_CLASS_PXE 343
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.
Overall looks good, I'd prefer shardy to lgtm.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dtantsur, elfosardo, juliakreger, stbenjam The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Build SUCCESS, see build http://10.8.144.11:8080/job/dev-tools/1325/ |
/lgtm |
A new version was pushed to https://quay.io/repository/metal3-io/ironic since ipv6 support was added in metal3-io/ironic-image#107 This PR can be used to verify the integration tests are still working OK
This commit adds support for IPv6. When $PROVISIONING_IP is specified, which may be an IPv6 address, the various containers will wait for that IP to become available on an interface. If the IP is IPv6, then we use an IPv6-specific configurations. Note, IPv6 hosts are expected to be using UEFI boot, as we use snponly.efi. snponly.efi uses the UEFI network stack instead of the iPXE drivers. When using EDK2 OVMF + iPXE + ipxe.efi, we have seen lock-ups in initialization of the hardware devices. As neither CentOS nor RHEL distribute iPXE builds with IPv6 support, we build them from source as part of the container build. Conflicts: Dockerfile configure-ironic.sh Related metal3-io change metal3-io#107 (cherry picked from commit 2ad2b0d)
Bug 1884155: Explicitly set json_rpc.auth_strategy to noauth
This commit adds support for IPv6. When $PROVISIONING_IP is specified,
which may be an IPv6 address, the various containers will wait for that
IP to become available on an interface.
If the IP is IPv6, then we use an IPv6-specific configurations. Note,
IPv6 hosts are expected to be using UEFI boot, as we use snponly.efi.
snponly.efi uses the UEFI network stack instead of the iPXE drivers.
When using EDK2 OVMF + iPXE + ipxe.efi, we have seen lock-ups in
initialization of the hardware devices.
As neither CentOS nor RHEL distribute iPXE builds with IPv6 support, we
build them from source as part of the container build.