You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When adding an additionalTrustBundle to the aicli parameters file and creating the cluster, the installation fails at the preparing phase with the following error message:
Container images availability: Failed to fetch container images needed for installation from quay.io/openshift-release-dev/ocp-release:4.13.9-x86_64,quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:6367174e22dca6a79d2aca3de974ed38499fb9cd10b7d845143cb82211b7bb02,quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:eba22f67551d60674a8c9550b9284f2a0540b2a69f5e3c12b7cb2d943684b2a3. This may be due to a network hiccup. Retry to install again. If this problem persists, check your network settings to make sure you’re not blocked.
This issue appears to be very similar to the RedHat bugzilla 2038013 referenced HERE
The parameters file I am using to create the cluster is as follows (temporary ca cert so I will show the full cert in the configuration):
It looks like the additionalTrustBundle is applied to the installconfig, however, I'm wondering if there is something else that needs to be done for the discovery iso to trust this ca cert. Do we need to apply an ignition configuration to the discovery iso as well for this to apply properly?
One observation, if I manually add the ca cert via the "Host Discovery" -> "Add Host" -> "Configure cluster-wide trusted certificates" option in the cluster console, regenerate the iso and boot off of it, then the installation proceeds properly, the installconfig with the above process then has two copies of the same certificate (duplicated) in the additionalTrustBundle section.
Is this a possible bug, or, is it something I may be doing wrong here?
The text was updated successfully, but these errors were encountered:
Does the assisted installer web interface set the additionalTrustBundlePolicy to Proxyonly when manualy adding in the cert through the interface, or, does it set it to Always? I'm wondering if the api interface sets it to Proxyonly (default) when not specified. I cannot tell if this is an issue with the parameters file AdditionalTrustBundle yaml or if this is a setting I'm missing (additionalTrustBundlePolicy) in the paremeters file, or, if this is a bug/enhancement for aicli.
Reference: Proxy settings for CA as mentioned HERE
can you try with the extra keyword registry_url: testk-disconnecter.ipv6only:5000
this will take care of fetching the cert and putting it in the install config, along with setting image content source policies, which i believe are what's missing in your case
Hi,
When adding an additionalTrustBundle to the aicli parameters file and creating the cluster, the installation fails at the preparing phase with the following error message:
This issue appears to be very similar to the RedHat bugzilla 2038013 referenced HERE
The parameters file I am using to create the cluster is as follows (temporary ca cert so I will show the full cert in the configuration):
The installconfig for this parameters file, pulled down using 'aicli download installconfig ocp', pull-secret removed, is as follows:
It looks like the additionalTrustBundle is applied to the installconfig, however, I'm wondering if there is something else that needs to be done for the discovery iso to trust this ca cert. Do we need to apply an ignition configuration to the discovery iso as well for this to apply properly?
One observation, if I manually add the ca cert via the "Host Discovery" -> "Add Host" -> "Configure cluster-wide trusted certificates" option in the cluster console, regenerate the iso and boot off of it, then the installation proceeds properly, the installconfig with the above process then has two copies of the same certificate (duplicated) in the additionalTrustBundle section.
Is this a possible bug, or, is it something I may be doing wrong here?
The text was updated successfully, but these errors were encountered: