Description of problem: Creating a SNO IPv6 cluster that uses "Use a temporary 60-day domain" option fails with IP registration error Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create a SNO cluster that uses the service configured route53 domain 2. Set Proxy and Download image 3. On a network with IPv6, boot up the server 4. Start installation Actual results: Installation will fail with error: --- Cluster installation failed Failed to create DNS record sets for base domain: assistedinstaller.sysdeseng.com: InvalidChangeBatch: [Invalid Resource Record: 'FATAL problem: ARRDATAIllegalIPv4Address (Value is not a valid IPv4 address) encountered with 'fd2e:6f44:5dd8::85''] status code: 400, request id: d0cea846-5edf-4f1d-ac94-9c2829456773. Reset the installation process to return to the configuration and try again. Some hosts may need to be re-registered by rebooting into the Discovery ISO. ---- Expected results: Registration to the DNS service to succeed for the IPv6 address Additional info:
Created attachment 1769972 [details] ipv6 registration error
@eran cohen since we do not support IPv6 from the cloud I don't think we should support rout53 updates. What do you think? Maybe we just need to block this option from the API?
If we do want to support IPv6, we should just create an AAAA dns record (instead of A record for IPv4). Otherwise, I guess we can indeed just block it when IPv6Support is enabled, in: https://github.com/openshift/assisted-service/blob/834faecd31fbccaa9716ca020da405a2d13296f8/internal/bminventory/inventory.go#L3960
It should be possible to deploy SNO using an on-prem assisted service, and it's up to the customer to deploy IPv6 clusters in this case. Therefore, we must be able to create an AAAA type DNS record in route53 for IPv6, even if we don't support IPv6 in the cloud.
As for IPv6 in the cloud, it's already blocked (IPv6 values are rejected for machine CIDR etc.), so this discussion seems irrelevant for cloud deployments.
@vemporop The route53 feature is not supported in our kubeapi deployments so I think it is relevant only for cloud. @atraeger what do you think?
AFAIK this happened in a non-cloud deployment. I also spoke with @itsoiref and he thinks we should support route53 for IPv6.
Route53 is for SaaS only, and even there it's not production or in the UI. We should add IPv6 support as very low priority.
Validated with Assisted Installer quay.io/ocpmetal/assisted-installer:c5c58c594badd91811edb7cd00c0de1b9e3a7ca9 Assisted Installer Agent quay.io/ocpmetal/assisted-installer-agent:72b14c873597f3883eab9af308fb803b344af2d0 Assisted Installer Controller quay.io/ocpmetal/assisted-installer-controller:c5c58c594badd91811edb7cd00c0de1b9e3a7ca9 Assisted Installer Service quay.io/ocpmetal/assisted-service:1e9a56ba4c76a165ec8925b2673b65f7be264802 and with route53 configured: $ dig -t aaaa api.ocp-edge-cdv-sno-0.assistedinstaller.sysdeseng.com ... ;; QUESTION SECTION: ;api.ocp-edge-cdv-sno-0.assistedinstaller.sysdeseng.com. IN AAAA ;; ANSWER SECTION: api.ocp-edge-cdv-sno-0.assistedinstaller.sysdeseng.com. 60 IN AAAA fd2e:6f44:5dd8::65 $ dig -t aaaa tesging.apps.ocp-edge-cdv-sno-0.assistedinstaller.sysdeseng.com ;; QUESTION SECTION: ;tesging.apps.ocp-edge-cdv-sno-0.assistedinstaller.sysdeseng.com. IN AAAA ;; ANSWER SECTION: tesging.apps.ocp-edge-cdv-sno-0.assistedinstaller.sysdeseng.com. 60 IN AAAA fd2e:6f44:5dd8::65
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.8.2 bug fix and 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-2021:2438