Re: Migration from registry.fp.o to quay.io

2023-09-07 Thread Pavel Raiskup 
On úterý 5. září 2023 19:02:57 CEST 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  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?

Not yet.  Unfortunately, Mock 5.0 swallows the Podman error output :(
so it is hard to diagnose what is going on on Copr builders.  I hope
we'll have better data with Mock 5.1.

Pavel


___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AWS Instances without tag FedoraGroup=*

2023-09-07 Thread Pavel Raiskup 
JFYI, I just updated the script Mirek had, and created a simple cron job
on one of our staging VMs that collects some AWS instance statistics.
Result is hosted here:

https://copr-be-dev.cloud.fedoraproject.org/infra-stats/

Especially interesting might be the list of currently "erroring"
instances:

https://copr-be-dev.cloud.fedoraproject.org/infra-stats/last-run-errors.log

Pavel


On neděle 3. září 2023 20:59:15 CEST Miroslav Suchý wrote:
> According our SOP
>
> https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/aws-access/#_role_and_user_policies
> 
>Users MUST tag resources with their FedoraGroup tag within one day, or the 
> resource may be removed.
> 
> I created a small script and queried all resources in all regions for 
> resources without this tag. I am NOT going to 
> delete resources without this tag as that would destroy half of the 
> infrastructure. Please check if one of these 
> resources is yours and properly tag them. (BTW when you will work on that, 
> please add tag Owner=* too):
> 
> Region: ap-south-2
> 
> Region: ap-south-1
> Instances:
>   * mref1.aps1.stream.centos.org (i-0f566f5a8d0544a9d)
> Volumes - [id (attached to instance)]:
>   * vol-04ba60d39cfda0873 (mref1.aps1.stream.centos.org)
>   * vol-0624a43d78bbcf1e3 (mref1.aps1.stream.centos.org)
>   * vol-0dbcb65fadcadfd56 (N/A)
> 
> Region: eu-south-1
> 
> Region: eu-south-2
> 
> Region: me-central-1
> 
> Region: il-central-1
> 
> Region: ca-central-1
> Instances:
> Volumes - [id (attached to instance)]:
>   * vol-067b5f163d2320171 (cloud-fedora-34-aws-ssd)
>   * vol-07a41964b391cbe75 (cloud-fedora-34-aws-ssd)
>   * vol-05fa6f0557ab1e44b (cloud-fedora-34-aws-ssd)
>   * vol-00d79ef4b4e1f92e8 (cloud-fedora-34-aws-ssd)
>   * vol-0712085157d0bade9 (cloud-fedora-34-aws-ssd)
>   * vol-037fb93e199476ee1 (cloud-fedora-34-aws)
> 
> Region: eu-central-1
> Instances:
>   * risc-v koji hub (i-096911a251a31b09f)
>   * mref1.euc1.stream.centos.org (i-0db35e5f70750e87f)
>   * vault.euc1.centos.org (i-0bc52b0cc68e4499d)
> Volumes - [id (attached to instance)]:
>   * vol-0ce62ad946d5356e9 (id.dev.centos.org)
>   * vol-0e630691e76128447 (proxy36.fedoraproject.org)
>   * vol-0bd681a8a7537d2e7 (minetest)
>   * vol-05b6b70293a262e2b (risc-v koji hub)
>   * vol-0a6a0692e6db3a4cd (risc-v koji hub)
>   * vol-06e0ad3a62ff40ee4 (mref1.euc1.stream.centos.org)
>   * vol-0fd3b08bd32b095b7 (mref1.euc1.stream.centos.org)
>   * vol-0fccc73d1328ff978 (vault.euc1.centos.org)
> 
> Region: eu-central-2
> 
> Region: us-west-1
> Instances:
> Volumes - [id (attached to instance)]:
>   * vol-b07165de (N/A)
>   * vol-b82037d6 (N/A)
>   * vol-54657c3a (N/A)
>   * vol-8349ade2 (N/A)
>   * vol-3ffc2b1f (N/A)
> 
> Region: us-west-2
> Instances:
>   * mref1.uw2.stream.centos.org (i-0cc5dceddb5b661af)
>   * proxy09.fedoraproject.org (i-07a30fbb93ec0030d)
>   * aarch64-test02.fedorainfracloud.org (i-09d5619b3782ff940)
>   * pdns3.uw2.centos.org (i-0d448e1f3f6552ce1)
>   * vault.uw2.centos.org (i-08f1d848cc1da073a)
> Volumes - [id (attached to instance)]:
>   * vol-0a3391b6d83a69e3e (mref1.uw2.stream.centos.org)
>   * vol-0df5eb0cf0d4e8855 (mref1.uw2.stream.centos.org)
>   * vol-070ba525db8d62425 (proxy09.fedoraproject.org)
>   * vol-0ad5c4cde450a9bdd (aarch64-test02.fedorainfracloud.org)
>   * vol-0c728f179988d4f1c (pdns3.uw2.centos.org)
>   * vol-48b8ec21 (N/A)
>   * vol-a998df91 (N/A)
>   * vol-06173c2bf59801079 (N/A)
>   * vol-03f61f31b964390b4 (N/A)
>   * vol-0acf2f1309656dbf0 (f37-test.fedorainfracloud.org)
>   * vol-09b92bac86df1d577 (vault.uw2.centos.org)
>   * vol-074066a4fb17c2ccd (f38-test.fedorainfracloud.org)
>   * vol-05c43dd45de9ec8dc (f39-test.fedorainfracloud.org)
>   * vol-60cc8458 (N/A)
> 
> Region: af-south-1
> Instances:
>   * proxy33.fedoraproject.org (i-091c3a0a9b51b746c)
>   * mref1.afs1.stream.centos.org (i-05e8706b4d1c1dbe3)
> Volumes - [id (attached to instance)]:
>   * vol-0474b44ac60470546 (proxy33.fedoraproject.org)
>   * vol-00ffe8821d7313bbf (mref1.afs1.stream.centos.org)
>   * vol-02b6f520ece872075 (mref1.afs1.stream.centos.org)
> 
> Region: eu-north-1
> 
> Region: eu-west-3
> Instances:
>   * pdns1.euw3.centos.org (i-07724f80561513ae4)
>   * people.euw3.centos.org (i-0629a7c9146e04290)
> Volumes - [id (attached to instance)]:
>   * vol-01517db42903637d9 (mirrorlist.euw3.aws.centos.org)
>   * vol-00c760fbdd555a77d (pdns1.euw3.centos.org)
>   * vol-033eed789811e4d73 (people.euw3.centos.org)
>   * vol-0879d3b255788e2b9 (people.euw3.centos.org)
>   * vol-0940073018c7c7424 (wiki.stg.centos.org)
> 
> Region: eu-west-2
> Instances:
>   * mon2.stg.centos.org (i-0e2dfdfd40502033d)
>   * buildlogs.euw2.centos.org (i-0d3da2203fcde2803)
>   * blog.stg.centos.org (i-0ff49a8f0cb580006)
>   * mref1.euw2.stream.centos.org (i-01e8f6a3aaf0fbc7c)
>   * www-node3.centos.org (i-0b7fd297c9c3e3070)
> Volumes - [id (attached to instance)]:
>   * vol-0fdf7047099b942c3 (forums.centos.org)
>   * vol-0a031eb0b5d5b43ab (mref1.euw2.stream.centos.org

Re: Migration from registry.fp.o to quay.io

2023-09-07 Thread Michal Konecny 
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).


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  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 stakeholder

Sure, 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@lists.fedoraproject.org
To unsubscribe send an email toinfrastructure-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To

Re: Migration from registry.fp.o to quay.io

2023-09-07 Thread Neal Gompa 
On Thu, Sep 7, 2023 at 10:15 AM Michal Konecny  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!
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AWS Instances without tag FedoraGroup=*

2023-09-07 Thread Kevin Fenzi 
On Thu, Sep 07, 2023 at 11:28:18AM +0200, Pavel Raiskup wrote:
> JFYI, I just updated the script Mirek had, and created a simple cron job
> on one of our staging VMs that collects some AWS instance statistics.
> Result is hosted here:
> 
> https://copr-be-dev.cloud.fedoraproject.org/infra-stats/
> 
> Especially interesting might be the list of currently "erroring"
> instances:
> 
> 
> https://copr-be-dev.cloud.fedoraproject.org/infra-stats/last-run-errors.log

Nice!

I think dkirwan should know about Discourse-test and mobrien should know
about mobrien-test, and I think the rest are centos ones?

kevin
--
> 
> Pavel
> 
> 
> On neděle 3. září 2023 20:59:15 CEST Miroslav Suchý wrote:
> > According our SOP
> >
> > https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/aws-access/#_role_and_user_policies
> > 
> >Users MUST tag resources with their FedoraGroup tag within one day, or 
> > the resource may be removed.
> > 
> > I created a small script and queried all resources in all regions for 
> > resources without this tag. I am NOT going to 
> > delete resources without this tag as that would destroy half of the 
> > infrastructure. Please check if one of these 
> > resources is yours and properly tag them. (BTW when you will work on that, 
> > please add tag Owner=* too):
> > 
> > Region: ap-south-2
> > 
> > Region: ap-south-1
> > Instances:
> >   * mref1.aps1.stream.centos.org (i-0f566f5a8d0544a9d)
> > Volumes - [id (attached to instance)]:
> >   * vol-04ba60d39cfda0873 (mref1.aps1.stream.centos.org)
> >   * vol-0624a43d78bbcf1e3 (mref1.aps1.stream.centos.org)
> >   * vol-0dbcb65fadcadfd56 (N/A)
> > 
> > Region: eu-south-1
> > 
> > Region: eu-south-2
> > 
> > Region: me-central-1
> > 
> > Region: il-central-1
> > 
> > Region: ca-central-1
> > Instances:
> > Volumes - [id (attached to instance)]:
> >   * vol-067b5f163d2320171 (cloud-fedora-34-aws-ssd)
> >   * vol-07a41964b391cbe75 (cloud-fedora-34-aws-ssd)
> >   * vol-05fa6f0557ab1e44b (cloud-fedora-34-aws-ssd)
> >   * vol-00d79ef4b4e1f92e8 (cloud-fedora-34-aws-ssd)
> >   * vol-0712085157d0bade9 (cloud-fedora-34-aws-ssd)
> >   * vol-037fb93e199476ee1 (cloud-fedora-34-aws)
> > 
> > Region: eu-central-1
> > Instances:
> >   * risc-v koji hub (i-096911a251a31b09f)
> >   * mref1.euc1.stream.centos.org (i-0db35e5f70750e87f)
> >   * vault.euc1.centos.org (i-0bc52b0cc68e4499d)
> > Volumes - [id (attached to instance)]:
> >   * vol-0ce62ad946d5356e9 (id.dev.centos.org)
> >   * vol-0e630691e76128447 (proxy36.fedoraproject.org)
> >   * vol-0bd681a8a7537d2e7 (minetest)
> >   * vol-05b6b70293a262e2b (risc-v koji hub)
> >   * vol-0a6a0692e6db3a4cd (risc-v koji hub)
> >   * vol-06e0ad3a62ff40ee4 (mref1.euc1.stream.centos.org)
> >   * vol-0fd3b08bd32b095b7 (mref1.euc1.stream.centos.org)
> >   * vol-0fccc73d1328ff978 (vault.euc1.centos.org)
> > 
> > Region: eu-central-2
> > 
> > Region: us-west-1
> > Instances:
> > Volumes - [id (attached to instance)]:
> >   * vol-b07165de (N/A)
> >   * vol-b82037d6 (N/A)
> >   * vol-54657c3a (N/A)
> >   * vol-8349ade2 (N/A)
> >   * vol-3ffc2b1f (N/A)
> > 
> > Region: us-west-2
> > Instances:
> >   * mref1.uw2.stream.centos.org (i-0cc5dceddb5b661af)
> >   * proxy09.fedoraproject.org (i-07a30fbb93ec0030d)
> >   * aarch64-test02.fedorainfracloud.org (i-09d5619b3782ff940)
> >   * pdns3.uw2.centos.org (i-0d448e1f3f6552ce1)
> >   * vault.uw2.centos.org (i-08f1d848cc1da073a)
> > Volumes - [id (attached to instance)]:
> >   * vol-0a3391b6d83a69e3e (mref1.uw2.stream.centos.org)
> >   * vol-0df5eb0cf0d4e8855 (mref1.uw2.stream.centos.org)
> >   * vol-070ba525db8d62425 (proxy09.fedoraproject.org)
> >   * vol-0ad5c4cde450a9bdd (aarch64-test02.fedorainfracloud.org)
> >   * vol-0c728f179988d4f1c (pdns3.uw2.centos.org)
> >   * vol-48b8ec21 (N/A)
> >   * vol-a998df91 (N/A)
> >   * vol-06173c2bf59801079 (N/A)
> >   * vol-03f61f31b964390b4 (N/A)
> >   * vol-0acf2f1309656dbf0 (f37-test.fedorainfracloud.org)
> >   * vol-09b92bac86df1d577 (vault.uw2.centos.org)
> >   * vol-074066a4fb17c2ccd (f38-test.fedorainfracloud.org)
> >   * vol-05c43dd45de9ec8dc (f39-test.fedorainfracloud.org)
> >   * vol-60cc8458 (N/A)
> > 
> > Region: af-south-1
> > Instances:
> >   * proxy33.fedoraproject.org (i-091c3a0a9b51b746c)
> >   * mref1.afs1.stream.centos.org (i-05e8706b4d1c1dbe3)
> > Volumes - [id (attached to instance)]:
> >   * vol-0474b44ac60470546 (proxy33.fedoraproject.org)
> >   * vol-00ffe8821d7313bbf (mref1.afs1.stream.centos.org)
> >   * vol-02b6f520ece872075 (mref1.afs1.stream.centos.org)
> > 
> > Region: eu-north-1
> > 
> > Region: eu-west-3
> > Instances:
> >   * pdns1.euw3.centos.org (i-07724f80561513ae4)
> >   * people.euw3.centos.org (i-0629a7c9146e04290)
> > Volumes - [id (attached to instance)]:
> >   * vol-01517db42903637d9 (mirrorlist.euw3.aws.centos.org)
> >   * vol-00c760fbdd555a77d (pdns1.euw3.centos.org)
> >   * vol-033eed789811e4d73 (people.euw3.centos.org)
> >   * vol-0879d3b255788e2b9 (people.euw3.centos.org)
> >   * vol-094007301

Re: Migration from registry.fp.o to quay.io

2023-09-07 Thread Kevin Fenzi 
On Thu, Sep 07, 2023 at 11:07:15AM -0400, Neal Gompa wrote:
> On Thu, Sep 7, 2023 at 10:15 AM Michal Konecny  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


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Freeze Break Request: update fedora-repos-zchunk on composers

2023-09-07 Thread Kevin Fenzi 
The new fedora-repo-zdicts-2309.1-1.fc38 update has f39 zchunk
dictionaries, which should make the zchunk deltas better for f39. 

I'd like to update compose-branched01/compose-rawhide01/compose-x86_01
so we can get this advantage.

I think this is a pretty low impact change and we can always just back
out to the older version if something happens. 

+1s?

kevin


signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Freeze Break Request: update fedora-repos-zchunk on composers

2023-09-07 Thread Sandro 

On 9/7/23 22:30, Kevin Fenzi wrote:

I think this is a pretty low impact change and we can always just back
out to the older version if something happens.


Sounds reasonable. I'm still not sure if my +1 counts, but I give it 
anyway. ;)


+1

-- Sandro
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: AWS Instances without tag FedoraGroup=*

2023-09-07 Thread Miroslav Suchý 

Dne 07. 09. 23 v 20:49 Kevin Fenzi napsal(a):
Nice! I think dkirwan should know about Discourse-test and mobrien should know about mobrien-test, and I think the 
rest are centos ones?


Hmm, not everything:

Region: ca-central-1
Instances: (name, id, owner)
Volumes - [id (attached to instance, owner)]:
* vol-067b5f163d2320171 (cloud-fedora-34-aws-ssd, N/A)
* vol-07a41964b391cbe75 (cloud-fedora-34-aws-ssd, N/A)
* vol-05fa6f0557ab1e44b (cloud-fedora-34-aws-ssd, N/A)
* vol-00d79ef4b4e1f92e8 (cloud-fedora-34-aws-ssd, N/A)
* vol-0712085157d0bade9 (cloud-fedora-34-aws-ssd, N/A)
* vol-037fb93e199476ee1 (cloud-fedora-34-aws, N/A)

Region: us-east-1
Instances: (name, id, owner)
* N/A (i-0b369063062ca52c9, arrfab)
* N/A (i-0931da1d5eda4eb93, bstinson)

* N/A (i-0fc9ee46b558d8b43, AutoScaling)
* N/A (i-08c3bdc2cf1ad6c3a, AutoScaling)
* N/A (i-0b08fcde88335d021, AutoScaling)
* N/A (i-0854b37f391d8c53a, AutoScaling)
* N/A (i-03a7d143db378408c, AutoScaling)
* N/A (i-088625e35e83fd5e2, AutoScaling)

Volumes - [id (attached to instance, owner)]:

* vol-0b485e1085984051e (, AutoScaling)
* vol-0dc4d4d90f320ec5c (, AutoScaling)

* vol-0be047389daecc795 (N/A, kevin)
* vol-06c2c4d56f8ebdbdc (N/A, kevin)

* vol-0573cd537ac825417 (, AutoScaling)

* vol-0a38fb3de4a46f50e (, AutoScaling)

* vol-0a2c7dd4a3f56a738 (, arrfab)
* vol-078902c5902a0920d (, bstinson)

* vol-09bda4cc18f9d62bc (, AutoScaling)

* vol-059b3abc628b450c7 (, AutoScaling)

These are the cases where owner is set. The rest may be centos, but maybe not 
everything. :(

M.



--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue