On Thu, Sep 07, 2023 at 11:07:15AM -0400, Neal Gompa wrote:
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..
Yeah, I am not sure this is a big deal, as 99.999% of people will not
have any need to login there.
> 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.
We may be able to pull that information from logs on oci-registry01/02?
Or... now that we have logs going into splunk, we could ask them to just
look in splunk? ;)
> 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
it's actually SAML2, but yeah...
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.
Yeah, thats a bigger conversation we should start.
I'm not fully sure where...
> 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.
Yep. Agree 100%. We should make it so we can switch out if needed and
so things move smoothly without users having to change anything or even
know too much that it happened.
kevin