> where the provisioning network is on ipv6 and ipv4 To clarify, the provisioning network does not support dual stack - it must be either ipv4 or ipv6. > https://github.com/openshift/ironic-image/blob/master/scripts/ironic-common.sh#L27 Yes it does appear that this assumes the short form ipv6 address, but if you use the short form in the install-config everything works OK?
> Yes it does appear that this assumes the short form ipv6 address, but if you > use the short form in the install-config everything works OK? My colleague @Jatan was on remote session when he encountered this issue, as per remote session activity notes; ------- - We scaled down the cluster-baremetal-operator and changed the PROVISIONING_IP environment variable in all the containers under metal3 pod deployment. <--- changed to short form - The new metal3 pod started the ironic agent properly and we could see all the ironic services up and running. ------- We have suggested customer to change the clusterprovisioningip in the install-config to a short form value of IPv6 and then check if the installation goes through or not, customer is yet to update on that. -Niket
Verified on version 4.10.0-0.nightly-2021-10-14-061552 install-config.yaml: ... provisioningNetworkCIDR: fd00:1101:0:1::/64 bootstrapProvisioningIP: fd00:1101:0000:0001:0000:0000:0000:0002 clusterProvisioningIP: fd00:1101:0000:0001:0000:0000:0000:0003 ... Installation completes successfully.
@bfournier Bob, can we please have Doc Text to assist in developing a Release Notes entry for this bug? Thanks!
Tony - the doc text was added on January 6, let me know if more is needed.
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 (Moderate: OpenShift Container Platform 4.10.3 security update), 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/RHSA-2022:0056