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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
