I have opened an infra ticket asking if there were guidelines about the use of the CentOS repository on quay.io for SIG [1].
I was told to ask the board to set the expectations, so here I am :)
For the record, here were the questions I've asked: What's the current recommendation for SIGs wanting to use quay for images? Is there a mechanism in place for quay to provide access to a subset of the repository? Should each SIG create their own space? If so, are there best practices on how to mark that repository as being "official"?
[1] https://pagure.io/centos-infra/issue/1000
For the record, the Hyperscale SIG is currently using Quay for our container image builds: https://quay.io/repository/centoshyperscale/centos
This is documented at https://sigs.centos.org/hyperscale/content/containers/ (usage) and https://sigs.centos.org/hyperscale/internal/containers/ (releng / build).
So what we (I) did for the Hyperscale SIG accounts was that we created the accounts with our SIG name:
... and so on.
These accounts/groups have their primary email address set to our SIG alias email so that account resets and recovery will go to something that the Project can redirect to someone else in the event everyone is gone.
Metadata Update from @jcpunk: - Issue assigned to jwboyer
This is probably a good topic to document at the Doc meetup after Connect
A long overdue update.
From the Board perspective, the pattern that the Hyperscale SIG has establish is the recommended approach. Using an organization in Quay.io that clearly delineates their images apart from CentOS Stream proper images is essentially the requirement. For example:
quay.io/repository/centos<SIG>/<images>
or
quay.io/repository/centos-<SIG>/<images>
are sufficient. SIGs that wish to produce container images should note their locations on their documentation pages.
There was an open question around subgroups under organziations but that is not possible in Quay and not currently on the roadmap. There is a feature that can be enabled to support nested repository names, but that is not attached to permissions/RBAC in any way so that can't be used for subgroups under a common organization. It is also not enabled on Quay.io in any case.
Metadata Update from @jwboyer: - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.