On Thu, Sep 7, 2023 at 10:15 AM Michal Konecny <mkonecny(a)redhat.com> wrote:
So I contacted William Dettelback from quay.io Team about the feedback I got here.
This is the e-mail I sent:
```
1) Mock switched to "--use-bootstrap-image" (podman pulling images
from various registries by default) and we had no single issue reported
against the Fedora's registry, but CentOS (on quay.io) gives us random
"pull" failures:
https://github.com/rpm-software-management/mock/issues/1191
Are you aware of this issue?
2) Quay.io is moving into console.redhat.com[2], which makes it even less
fun since RH accounts for the console require giving a lot more
information.
Do we need to be Red Hat customers to access that? Could it be possible to
allow Fedora Account System login?
3) There is a rate limiting enabled for pulling on quay.io [3]. Could it be possible to
remove that if some Fedora services start hitting that?
```
And here is the response I got:
```
Thanks for reaching out- we'd certainly like to support your migration. Fedora makes
perfect sense as a tenant on quay.io. Let me try to answer your questions:
1) Not aware of this issue- I don't believe anyone has raised a support ticket with
us on it.
Wasn't clear to me from the GH issue if you had a stable reproducer. If you do,
please feel free to raise a bug report at
https://issues.redhat.com/projects/PROJQUAY
and we can take a look.
2) Our long term plan is to move all authenticated web UI access to
console.redhat.com
but we will keep our quay.io web UI available for unauthenticated access
(e.g. google search results linking to public images). So only users who need
authenticated
access to your namespace(s)- for example to administer a Team, etc.. would need to sign
up
for a Red Hat Account. Robot account / docker CLI access will still work directly and not
require RH SSO- so your automation can still push images, etc..
We have no plans to integrate the Fedora Account System login- but open to discuss what
that
could look like (esp. if it supports OIDC).
3) We can disable the rate limiting on your namespace(s)- it's usually not a problem,
we do this
for other Red Hat teams (e.g. Openshift). I would be interested to understand more of
your
expected traffic loads for push/pull so we can plan accordingly on our side.
```
1) Corresponds with what Pavel wrote. I sent it before I noticed the response from
Pavel.
2) As FAS is supporting OIDC, we can start negotiating that. Or it would be just
mandatory for maintainers of quay.io namespaces to have RedHat account (not that different
from managing AWS now).
AWS supports being accessed via OIDC SSO, so it's possible to (for
example) tie Fedora's AWS account to FAS. I would really like to see
FAS supported by Red Hat SSO across the board, especially since now
CentOS contributors are forced to deal with Red Hat's Jira instance
with the completion of the RHEL-in-JIRA (RIJ) project.
3) That is really great to hear. Do we have any traffic statistics
for registry.fp.o in that regard?
Can we have an alias for registry.fp.o that goes to our quay namespace
too? Breaking the world is not fun, and if Quay doesn't work out, we
should be able to painlessly switch to something else.
--
真実はいつも一つ!/ Always, there's only one truth!