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).
3) That is really great to hear. Do we have any traffic statistics for registry.fp.o in that regard?
Any thoughts from folks here?
Michal
On 05. 09. 23 19:02, Kevin Fenzi wrote:
On Mon, Sep 04, 2023 at 01:57:34PM -0400, Neal Gompa wrote:On Mon, Sep 4, 2023 at 12:47 PM Pavel Raiskup <praiskup@xxxxxxxxxx> wrote:On pondělí 4. září 2023 15:35:41 CEST Michal Konecny wrote:Hi everyone, I finished investigation for migration from registry.fp.o to quay.io. It is available in ARC investigation document [0]. The investigation ticket [1] is on fedora-infra tracker.JFYI, 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 So the stability might not be as ideal as with the current registry.Huh, good to know. Is this something anyone has taken to upstream quay.io?I'm not super-enthused about this from a few perspectives: 1. Core artifacts should be able to be produced, hosted, and consumed from Fedora infrastructure.Well, they still are in koji of course...2. Quay ultimately does not need to care about Fedora as a stakeholderSure, but do we have complex needs that require stakeholderness (ok, thats not a word, but you know what I mean. ;)3. Quay.io is moving into console.redhat.com[a], which makes it even less fun since RH accounts for the console require giving a lot more information.Huh, good to know. Of course the vast majority of people will just pull from it, never look at the ui. I think it would be good for us to try and talk to quay.io folks and see if there's any issues or reasons not to head that way. kevin
_______________________________________________ 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
_______________________________________________ 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
