removes pulling and loading of registry api image in operator deploy task #2667
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
this was probably a breadcrumb left over from when the registry api was in this repo. so it made sense to load it into the kind node because it is common loading locally built images into the kind cluster for testing. but not the registry server lives in its own repo and is publicly avaialable, when the operator creates the deployment for the registry server inside of the cluster it just pulls it itself. this removing the need for us to pull the image ourselves and loading it into kind. there were also problems doing the pulling and loading of a remote image because docker pulls only the image that matches your host architecture whereas kind loads the image with `--all-platforms` as the default. this causes errors because it can't load the full imagine manifests because docker never pulled them for the other platforms. we could tell kind to load it only for the platform of the host but its pointless given its a public image now and we aren't building it as part of this task. the operator and proxyrunner images loaded fine because we build them using `ko` so all platforms are built by default resulting in kind having no issues loading them. Signed-off-by: Chris Burns <29541485+ChrisJBurns@users.noreply.github.com>
ChrisJBurns
changed the title
ChrisJBurns
changed the title
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2667 +/- ##
=======================================
Coverage 55.22% 55.22%
=======================================
Files 315 315
Lines 30124 30124
=======================================
Hits 16635 16635
Misses 12046 12046
Partials 1443 1443 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
rdimitrov
approved these changes
Nov 19, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This was likely a leftover from when the registry API lived in this repository. At that time, it made sense to load the image into the kind node because it’s common to load locally built images into a kind cluster for testing. Now that the registry server lives in its own repository and the image is publicly available, the operator simply pulls it when creating the registry deployment inside the cluster. This means we no longer need to pull the image ourselves or load it into kind.
There were also complications with pulling and loading remote images. Docker only pulls images for the host architecture, while
kind load(by default) expects all platforms via--all-platforms. This mismatch causes errors because Docker never downloaded the multi-arch manifests that kind tries to load. We could instruct kind to load only the host platform, but since the image is public and no longer part of the local build process, that would be unnecessary.The operator and proxyrunner images loaded without issues because we build them with
ko, which produces multi-arch images by default, so kind can successfully load them.