feat(RHEL-50244): support for new flatpak registries #933
Conversation
There was a problem hiding this comment.
(Commenting here just so that a thread is created.)
@ralphbean it looks good overall, but what about creating images in Pyxis? With no changes, we would simply create the image in Pyxis as usual and add a repository entry with registry=registry.access.redhat.com and repository=myprod/myflatpak
I think that's an issue. For one, RHEC will wrongly show that this image can be pulled from registry.access.redhat.com or registry.redhat.io which is not true. And also, Clair-wrapper is translating this entry back to quay.io/redhat-prod/myprod----myflatpack to pull the image and check for vulnerabilities.
So the question is, what is the correct way to create this image in Pyxis? Should it use flatpacks.registry.access.redhat.com as the registry? Is that what RHEC needs to show it in the right place? And what about clair-wrapper? Will it need to start looking for these entries as well?
There was a problem hiding this comment.
Should it use flatpacks.registry.access.redhat.com as the registry?
yes.
Is that what RHEC needs to show it in the right place?
also yes
And what about clair-wrapper? Will it need to start looking for these entries as well?
yes, I can open a ticket for that to container health team. Thanks for raising it. We also need to let the Atlas team know to be importing the SBOMs for images in that registry.
Finally, I expect that the catalog probably won't look right. I already prepared stakeholders for that. We will have to see what is broken once we get something into staging and file tickets for the catalog team too.
There was a problem hiding this comment.
OK, thanks for confirming. So somebody will need to modify create_container_image.py to support that first. So either Ralph can give it a go, or you can create a RELEASE Jira and I can take a look at that.
yes, I can open a ticket for that to container health team.
OK, sounds good.
ralphbean
force-pushed
the
rh-flatpaks
branch
2 times, most recently
from
b297efd to
cbec142
Compare
There was a problem hiding this comment.
I think a test like https://github.com/konflux-ci/release-service-catalog/blob/development/tasks/managed/create-advisory/tests/test-create-advisory-prod-repo.yaml would be nice for this change
| ## Changes in 6.1.0 | ||
| * Add check for custom advisory id | ||
| * If `.releaseNotes.allow_custom_live_id` is set to `true` in the RPA, then a custom advisory live | ||
| id can be set via `.releaseNotes.live_id` and this will be used instead of requesting one from | ||
| Errata Tool API. | ||
| * If `.releaseNotes.allow_custom_live_id` is not set or `false` and `.releaseNotes.live_id` is set, | ||
| we will exit with an error. | ||
|
|
||
There was a problem hiding this comment.
I think adding to https://github.com/konflux-ci/release-service-catalog/blob/development/tasks/managed/publish-pyxis-repository/tests/test-publish-pyxis-repository-container-multiple-components.yaml or creating a similar test would be nice
ralphbean
force-pushed
the
rh-flatpaks
branch
2 times, most recently
from
c540bd3 to
2cc6336
Compare
|
Note to self: after the upcoming flatpak release, this needs a little rework. We should drop the |
Signed-off-by: Ralph Bean <[email protected]>
There's a new registry coming up PROJQUAY-8882. Signed-off-by: Ralph Bean <[email protected]>
|
PR needs rebase. 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-sigs/prow repository. |
|
It appears that PR is on hold, and a rebase is required. |
There's a new registry coming up PROJQUAY-8882.
Describe your changes
Support new flatpak registries.
Relevant Jira
Dependencies
Downstream
Checklist before requesting a review
do not mergelabel if there's a dependency PRrelease-service-maintainershandle if you are unsure who to tagSigned-off-by: My name <email>