ROX-34063: Fix v1tov2 image migration logic to set correct image name#19883
ROX-34063: Fix v1tov2 image migration logic to set correct image name#19883charmik-redhat wants to merge 2 commits intomasterfrom
Conversation
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ests Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| // Each imageIDV2 will map to a single digest, but SQL wants us to apply an aggreate func to all selected fields | ||
| // when grouing by imageIDV2. So we need to select the digest with a min aggregate, | ||
| // which will be a no-op for a single value. |
There was a problem hiding this comment.
This comment was no longer relevant
🚀 Build Images ReadyImages are ready for commit 0899fa6. To use with deploy scripts: export MAIN_IMAGE_TAG=4.11.x-588-g0899fa6cdd |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #19883 +/- ##
==========================================
- Coverage 49.58% 49.58% -0.01%
==========================================
Files 2766 2766
Lines 208540 208551 +11
==========================================
Hits 103408 103408
- Misses 97460 97471 +11
Partials 7672 7672
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@charmik-redhat: The following tests failed, say
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. |
Description
Bug summary:
After the
deployment_containersare migrated to haveimageV2Idpopulated, image reprocessing is used to migrate images fromimagestable toimages_v2table. This is done usingreprocessImageV2function in the reprocessor as follows:GetImageContainerViewsimagestable usingGetImageMetadataon imageV1 datastoreConvertToV2 functionimages_v2table using imageV2 datastoreThe conversion in
ConvertToV2copies the legacy image's name directly. However,imagestable only stores one image per digest whereasimages_v2can store multiple images per digest with different names. So the name of the deployed container image can be different than the V1 image obtained byGetImageMetadata. UsingConvertToV2directly on V1 image can result in migrated V2 image to have mismatched name and ID.Fix
Pass the deployed image's name (obtained from GetContainerImageViews) through to the conversion function so the migrated V2 image gets the correct name and derived ID.
ConvertToV2WithNameOverride(pkg/images/utils/convert_utils.go): New function that accepts a *storage.ImageName override, so the converted V2 image uses the deployed image's name (andcorrect derived ID) instead of the legacy image's name.
ContainerImageView(central/deployment/views/container_images.go): Added image name fields (Registry, Remote, Tag, FullName) and a GetImageName() getter.GetContainerImageViews(central/deployment/datastore/internal/store/postgres/full_store.go): Updated the SQL query to select and group by the image name fields.reprocessImageV2(central/reprocessor/reprocessor.go): Now receives the deployed image's name from the caller and passes it to ConvertToV2WithNameOverride during legacy-to-V2 migration.User-facing documentation
Testing and quality
Automated testing
How I validated my change
imageIDV2indeployments_containers