(bugfix): run bundle and run bundle-upgrade - update registry pod index directory#5894
Conversation
The registry pod index directory now includes the CatalogSource name to prevent conflicts between indexes in the same directory Signed-off-by: Bryce Palmer <bpalmer@redhat.com>
|
/hold needs more testing and discussion |
|
Change looks good to me after testing some scenarios. Will approve after testing with some more images. |
Signed-off-by: Bryce Palmer <bpalmer@redhat.com>
|
I performed some fairly extensive tests to verify that these changes work as expected and resolve the bug. From what I can tell, these changes do resolve the bug and work as expected. For more details on the tests expand this dropdown (warning this is a lot of stuff, ~400 lines of Markdown)run
|
Signed-off-by: Bryce Palmer <bpalmer@redhat.com>
rashmigottipati
left a comment
There was a problem hiding this comment.
/lgtm
Tested various scenarios extensively and these changes don't break any existing scenarios and also fixes a traditional upgrade use-case bug.
|
/hold cancel |
|
/cherry-pick v1.22.x |
|
@everettraven: #5894 failed to apply on top of branch "v1.22.x": 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 kubernetes/test-infra repository. |
|
/cherry-pick v1.22.x |
|
@everettraven: new pull request created: #5920 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 kubernetes/test-infra repository. |
The registry pod index directory now includes the CatalogSource name to prevent conflicts between indexes in the same directory
Signed-off-by: Bryce Palmer bpalmer@redhat.com
Description of the change:
Update the registry pod index directory to include the
CatalogSourcename.Motivation for the change:
Potential fix for #5870
run bundle-upgradewas not working properly when upgrading a traditionally (OLM) installed operator for FBC indexes. It seems this issue is due to multiple indexes being in the same directory that have repeating package definitions.This change makes it so that the directory indexes are stored in correlate to the
CatalogSourcethat is created/used for the upgrade. This seems to have resolved the issue.(This change also affects
run bundleas it will now use the same directory logic for storing indexes)Checklist
If the pull request includes user-facing changes, extra documentation is required:
changelog/fragments(seechangelog/fragments/00-template.yaml)website/content/en/docs