OSDOCS-17918: configuring external registry#107199
Conversation
|
@skopacz1: This pull request references OSDOCS-17918 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
| - Name: Configuring your cluster to use an external registry | ||
| File: configuring-registry-external | ||
| Distros: openshift-enterprise |
There was a problem hiding this comment.
Now that I think about it, perhaps this doc would belong more in the disconnected environment docs. After all, all of the prereq tasks i link to are in this section already
There was a problem hiding this comment.
@skopacz1 will this page must appear under the OVE docs? It's about on how to step-out from the feature and use your own images (note that the use of an external registry is required mostly in disconnected environments, but potentially it couldn't be in connected ones).
There was a problem hiding this comment.
It would be tough to place them directly alongside the install docs for OVE because that procedure exists in the Agent install docs right now, and this is technically a post-install task. If we wanted all of these docs to exist together, we would want to talk with Michal and my content strategist about creating a new location for all the docs related to this feature suite.
There was a problem hiding this comment.
The key point here is that this is not a "general" procedure potentially valid for any cluster, but only for those ones that have been installed thanks to the "I don't want to use an external registry" feature - and currently the only valid case is OVE.
There was a problem hiding this comment.
That's a valid point. I have an admonition here warning users about that, but I can also add it to the prerequisites in the procedure itself.
Let me know if you think we need to make that point more clear some other way as well
There was a problem hiding this comment.
It still looks a little bit weird, because by default a (connected) cluster installation does not require an external registry managed by the user (the customer can use quay.io).
The current article is valid only in the scope of the (let me use a tech term) NoRegistryClusterInstall feature - which in turn is meant to be used for disconnected baremetal clusters.
There was a problem hiding this comment.
I can move this doc to the disconnected environment docs in that case. That was the other candidate for where to place this document, and your confirmation that this content is not applicable to connected use cases makes it seem like a better location that this section for registries in general
| toc::[] | ||
|
|
||
| [role="_abstract"] | ||
| If your cluster was installed without an external registry, you can configure the cluster to use an external registry as a postinstallation task in order to utilize a mirroring workflow for your image management. |
There was a problem hiding this comment.
🤖 [error] RedHat.TermsErrors: Use 'use' rather than 'utilize'. For more information, see RedHat.TermsErrors.
|
@skopacz1: This pull request references OSDOCS-17918 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
|
||
| .Prerequisites | ||
|
|
||
| * You have successfully performed a cluster update using images mirrored to your external image registry. |
There was a problem hiding this comment.
It may be worth noting, as an additional check, to ensure that the current clusterversion version resource is pointing to the new upgraded version. Not sure if it's too obvious, given the previous phrase
There was a problem hiding this comment.
What would the command for that be? oc get clusterversion? I can add a statement here about using that command to double check
There was a problem hiding this comment.
Yes. And the returned installed version must not be listed in the IRI status releases list.
|
|
||
| .Procedure | ||
|
|
||
| * Delete the by `InternalImageRegistry` custom resource running the following command: |
There was a problem hiding this comment.
| * Delete the by `InternalImageRegistry` custom resource running the following command: | |
| * Delete the singleton `InternalReleaseImage` resource by running the following command: |
| [role="_abstract"] | ||
| Before you can configure your cluster to use an external registry, you must prepare your environment with an image registry and perform an update using images on the registry. | ||
|
|
||
| To prevent the accidental deletion of the cluster's internal image registry, you cannot delete the `InternalImageRegistry` custom resource without first having completed the following tasks: |
There was a problem hiding this comment.
| To prevent the accidental deletion of the cluster's internal image registry, you cannot delete the `InternalImageRegistry` custom resource without first having completed the following tasks: | |
| To prevent the accidental deletion of the cluster's internal image registry, you cannot delete the `InternalReleaseImage` custom resource without first having completed the following tasks: |
There was a problem hiding this comment.
Thanks for catching this, idk where the first name came from to be honest 😅
|
|
||
| When you install a cluster using the method described in "Installing a cluster without an external registry", the cluster relies on images contained in the downloaded ISO for its lifecycle management. | ||
| However, you might want to configure your cluster to use an external image registry and mirror images to the registry instead. | ||
| To do this, you must set up an external registry, successfully complete an update using images from the external registry, and finally delete `InternalImageRegistry` custom resource, which maintains an internal image registry in the cluster. |
There was a problem hiding this comment.
| To do this, you must set up an external registry, successfully complete an update using images from the external registry, and finally delete `InternalImageRegistry` custom resource, which maintains an internal image registry in the cluster. | |
| To do this, you must set up an external registry, successfully complete an update using images from the external registry, and finally delete `InternalReleaseImage` custom resource, which maintains an internal image registry in the cluster. |
| - Name: Configuring your cluster to use an external registry | ||
| File: configuring-registry-external | ||
| Distros: openshift-enterprise |
There was a problem hiding this comment.
@skopacz1 will this page must appear under the OVE docs? It's about on how to step-out from the feature and use your own images (note that the use of an external registry is required mostly in disconnected environments, but potentially it couldn't be in connected ones).
|
@skopacz1: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
|
@skopacz1: This pull request references OSDOCS-17918 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
@skopacz1: This pull request references OSDOCS-17918 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
@skopacz1 I have only one comment/question: Should we align terminology related to different registry? External vs local vs internal registry. Is it unified in the official documentation? CC: @andfasano |
|
@mzasepaRedHat I think it would be a good idea to align the terminology, yes. Even better might be to create a small section where we define the different terms being used here and in the install doc. Do you think this alignment should be done in this PR, or would it be fine to address in another PR to ensure that this doc can be released in time for the 4.21 ISO release? I am currently working on other 4.22 things that might limit my capacity these next few weeks |
|
@skopacz1 Bot options (this PR or a dedicated one) are fine. Up to you. CC: @andfasano @zaneb |
|
The This is because your PR targets the If the update in your PR does NOT apply to version 5.0 onward, please re-target this PR to go directly into the appropriate |

OSDOCS-17918
Version(s): 4.21+
This PR adds a doc for converting your cluster to use an external image registry
QE review:
Preview: Configuring your cluster to use an external registry