infra/tickets
21
6
Fork 0
Code Issues 77 Projects Wiki Activity Actions

Migration of registry.fedoraproject.org to quay.io #11543

New issue
Open
opened 2023-09-25 11:10:45 +00:00 by zlopez · 75 comments
zlopez commented 2023-09-25 11:10:45 +00:00
Owner
Copy link

Describe what you would like us to do:

As the investigation is now done, we can follow the document and do the migration. It will be best to wait after Fedora 39 will be out as this will allow us to get rid of plenty of legacy workflow.

We will need some transition period, so the users still can access the content on registry.fp.o until we move everything on or it's no longer needed.

When do you need this to be done by? (YYYY/MM/DD)

Not urgent, needs to wait till F39 will be out.

# Describe what you would like us to do: ---- As the [investigation](https://pagure.io/fedora-infrastructure/issue/10386) is now done, we can follow the [document](https://fedora-arc.readthedocs.io/en/latest/registry_to_quay/index.html) and do the migration. It will be best to wait after Fedora 39 will be out as this will allow us to get rid of plenty of legacy workflow. We will need some transition period, so the users still can access the content on registry.fp.o until we move everything on or it's no longer needed. # When do you need this to be done by? (YYYY/MM/DD) ---- Not urgent, needs to wait till F39 will be out.
rishi commented 2023-11-30 21:36:40 +00:00
Copy link

Just to repeat what I mentioned a while before on the investigation ticket.

Toolbx still uses registry.fedoraproject.org for its fedora-toolbox images. From Fedora 39 onwards these images are produced by Fedora's nightly composes.

We are open to moving to quay.io but we need some migration period because the URL to the image is baked into the toolbox RPM, and we can't change it without knowing exactly what it would be.

Just to repeat what I mentioned a while before on the [investigation](https://pagure.io/fedora-infrastructure/issue/10386#comment-806812) ticket. Toolbx still uses `registry.fedoraproject.org` for its `fedora-toolbox` images. From Fedora 39 [onwards](https://fedoraproject.org/wiki/Changes/ToolbxReleaseBlocker) these images are produced by Fedora's nightly composes. We are open to moving to `quay.io` but we need some migration period because the URL to the image is baked into the `toolbox` RPM, and we can't change it without knowing exactly what it would be.
kevin commented 2023-11-30 22:54:34 +00:00
Owner
Copy link

FWIW, IMHO, we should try and redirect existing registry.fedoraproject.org to quay.io if tools will understand that. Or I guess proxy them if not. At least initially. This will allow us to 'fail back' if there's problems or we need to down the road. But I am not sure the details on if thats possible.

FWIW, IMHO, we should try and redirect existing registry.fedoraproject.org to quay.io if tools will understand that. Or I guess proxy them if not. At least initially. This will allow us to 'fail back' if there's problems or we need to down the road. But I am not sure the details on if thats possible.
zlopez commented 2024-01-18 15:25:52 +00:00
Author
Owner
Copy link

Metadata Update from @zlopez:

  • Issue assigned to t0xic0der
**Metadata Update from @zlopez**: - Issue assigned to t0xic0der
kevin commented 2024-01-24 21:03:01 +00:00
Owner
Copy link

So, there is some question about how we want to do things.

I personally think we should keep things pointed to the registry.fedoraproject.org, and then that redirects them to quay.io for the actual image.
The advantage of this is that we control it, and can repoint it somewhere else if we like, or run our own registry for some part of it and redirect other things.
It also means we can change it in our infra and it immediately would take effect.

If on the other hand, we change everything to say 'use quay.io', there's the advantage that we don't have to redirect and it's all on them.
But the downside is that if ever we need to change it again, we will have to change it in all the places it's currently set (documentation, podman, toolbox, etc).
Any changes will take rebuilding things and pushing out updates and be a long and slow process.

Can folks chime in with their thoughts on this so we can decide how to approach it?

So, there is some question about how we want to do things. I personally think we should keep things pointed to the registry.fedoraproject.org, and then that redirects them to quay.io for the actual image. The advantage of this is that we control it, and can repoint it somewhere else if we like, or run our own registry for some part of it and redirect other things. It also means we can change it in our infra and it immediately would take effect. If on the other hand, we change everything to say 'use quay.io', there's the advantage that we don't have to redirect and it's all on them. But the downside is that if ever we need to change it again, we will have to change it in all the places it's currently set (documentation, podman, toolbox, etc). Any changes will take rebuilding things and pushing out updates and be a long and slow process. Can folks chime in with their thoughts on this so we can decide how to approach it?
rishi commented 2024-01-25 02:33:22 +00:00
Copy link

So, there is some question about how we want to do things.

I personally think we should keep things pointed to the registry.fedoraproject.org, and then that redirects them to quay.io for the actual image.
The advantage of this is that we control it, and can repoint it somewhere else if we like, or run our own registry for some part of it and redirect other things.
It also means we can change it in our infra and it immediately would take effect.

If on the other hand, we change everything to say 'use quay.io', there's the advantage that we don't have to redirect and it's all on them.
But the downside is that if ever we need to change it again, we will have to change it in all the places it's currently set (documentation, podman, toolbox, etc).
Any changes will take rebuilding things and pushing out updates and be a long and slow process.

Yes, I am with you on this one, assuming that the underlying technical realities let us use registry.fedoraproject.org as a front.

A hard switch to quay.io can be done later once things have settled and we are confident about it. Until then, the possibly of a revert and all the associated churn, makes it wise to continue pointing the clients to registry.fedoraproject.org.

> So, there is some question about how we want to do things. > > I personally think we should keep things pointed to the registry.fedoraproject.org, and then that redirects them to quay.io for the actual image. > The advantage of this is that we control it, and can repoint it somewhere else if we like, or run our own registry for some part of it and redirect other things. > It also means we can change it in our infra and it immediately would take effect. > > If on the other hand, we change everything to say 'use quay.io', there's the advantage that we don't have to redirect and it's all on them. > But the downside is that if ever we need to change it again, we will have to change it in all the places it's currently set (documentation, podman, toolbox, etc). > Any changes will take rebuilding things and pushing out updates and be a long and slow process. Yes, I am with you on this one, assuming that the underlying technical realities let us use `registry.fedoraproject.org` as a front. A hard switch to `quay.io` can be done later once things have settled and we are confident about it. Until then, the possibly of a revert and all the associated churn, makes it wise to continue pointing the clients to `registry.fedoraproject.org`.
sumantrom commented 2024-01-25 03:18:56 +00:00
Copy link

So, there is some question about how we want to do things.

I personally think we should keep things pointed to the registry.fedoraproject.org, and then that redirects them to quay.io for the actual image.
The advantage of this is that we control it, and can repoint it somewhere else if we like, or run our own registry for some part of it and redirect other things.
It also means we can change it in our infra and it immediately would take effect.

If on the other hand, we change everything to say 'use quay.io', there's the advantage that we don't have to redirect and it's all on them.
But the downside is that if ever we need to change it again, we will have to change it in all the places it's currently set (documentation, podman, toolbox, etc).
Any changes will take rebuilding things and pushing out updates and be a long and slow process.

Yes, I am with you on this one, assuming that the underlying technical realities let us use registry.fedoraproject.org as a front.

A hard switch to quay.io can be done later once things have settled and we are confident about it. Until then, the possibly of a revert and all the associated churn, makes it wise to continue pointing the clients to registry.fedoraproject.org.

I am also +1 to this approach of keeping registry.fp.o as a front and then redirecting. I still would want to check out the latency situation after the redirect. Any chance you can give us a timeline for testing?

> > So, there is some question about how we want to do things. > > > > I personally think we should keep things pointed to the registry.fedoraproject.org, and then that redirects them to quay.io for the actual image. > > The advantage of this is that we control it, and can repoint it somewhere else if we like, or run our own registry for some part of it and redirect other things. > > It also means we can change it in our infra and it immediately would take effect. > > > > If on the other hand, we change everything to say 'use quay.io', there's the advantage that we don't have to redirect and it's all on them. > > But the downside is that if ever we need to change it again, we will have to change it in all the places it's currently set (documentation, podman, toolbox, etc). > > Any changes will take rebuilding things and pushing out updates and be a long and slow process. > > Yes, I am with you on this one, assuming that the underlying technical realities let us use `registry.fedoraproject.org` as a front. > > A hard switch to `quay.io` can be done later once things have settled and we are confident about it. Until then, the possibly of a revert and all the associated churn, makes it wise to continue pointing the clients to `registry.fedoraproject.org`. I am also +1 to this approach of keeping registry.fp.o as a front and then redirecting. I still would want to check out the latency situation after the redirect. Any chance you can give us a timeline for testing?
siosm commented 2024-02-12 12:06:46 +00:00
Copy link

I personally think we should keep things pointed to the registry.fedoraproject.org, and then that redirects them to quay.io for the actual image.
The advantage of this is that we control it, and can repoint it somewhere else if we like, or run our own registry for some part of it and redirect other things.
It also means we can change it in our infra and it immediately would take effect.

Oh, this is indeed a good idea. We started "migrating" to quay.io images in Fedora CoreOS land but this looks like a better approach if this works well.

> I personally think we should keep things pointed to the registry.fedoraproject.org, and then that redirects them to quay.io for the actual image. > The advantage of this is that we control it, and can repoint it somewhere else if we like, or run our own registry for some part of it and redirect other things. > It also means we can change it in our infra and it immediately would take effect. Oh, this is indeed a good idea. We started "migrating" to quay.io images in Fedora CoreOS land but this looks like a better approach if this works well.
ppisar commented 2024-02-27 08:52:54 +00:00
Copy link

May I ask what's the official place for Fedora containers now?

A documentation https://docs.fedoraproject.org/en-US/containers/#_where_to_find_the_containers points to registry.fedoraproject.org where the images were not updated since November 2023 https://registry.fedoraproject.org/repo/fedora/tags/.

May I ask what's the official place for Fedora containers now? A documentation <https://docs.fedoraproject.org/en-US/containers/#_where_to_find_the_containers> points to registry.fedoraproject.org where the images were not updated since November 2023 <https://registry.fedoraproject.org/repo/fedora/tags/>.
zlopez commented 2024-02-27 11:41:23 +00:00
Author
Owner
Copy link

Most of the projects hosted on registry.fp.o either moved or moving to quay.io. There is a Fedora organization on quay.io, where you should find most of the images.

Most of the projects hosted on registry.fp.o either moved or moving to quay.io. There is a [Fedora organization on quay.io](https://quay.io/organization/fedora), where you should find most of the images.
kevin commented 2024-02-27 15:33:10 +00:00
Owner
Copy link

Yes, but note... IMHO we should just keep using registry.fedoraproject.org and have it redirect, so in that case we shouldn't need to change any docs.

Yes, but note... IMHO we should just keep using registry.fedoraproject.org and have it redirect, so in that case we shouldn't need to change any docs.
rishi commented 2024-02-27 15:34:14 +00:00
Copy link

May I ask what's the official place for Fedora containers now?

Yes, just keep using registry.fedoraproject.org. :)

> May I ask what's the official place for Fedora containers now? Yes, just keep using `registry.fedoraproject.org`. :)
jlebon commented 2024-04-29 16:42:33 +00:00
Copy link

To clarify, are we saying that registry.fp.o should still be the canonical repo and that Quay.io is an implementation detail, or that the redirect is more of a backcompat thing but that the expectation is that eventually we shut down registry.fp.o? Clearly, the quay.io repos have already gone around and been documented quite some time now, so I don't know how realistic it is to consider it an implementation detail at this point.

A downside I raised in https://github.com/coreos/fedora-coreos-config/pull/2988 is that using registry.fp.o means that service is now also in your dependency path. Being dependent on less things being up is very valuable in a CI context.

To clarify, are we saying that registry.fp.o should still be the canonical repo and that Quay.io is an implementation detail, or that the redirect is more of a backcompat thing but that the expectation is that eventually we shut down registry.fp.o? Clearly, the quay.io repos have already gone around and been documented quite some time now, so I don't know how realistic it is to consider it an implementation detail at this point. A downside I raised in https://github.com/coreos/fedora-coreos-config/pull/2988 is that using registry.fp.o means that service is now also in your dependency path. Being dependent on less things being up is very valuable in a CI context.
kevin commented 2024-04-30 01:27:29 +00:00
Owner
Copy link

Yeah, I guess I was imagining that we would keep registry.fedoraproject.org for a while redirecting to quay.io and make sure there were not any big issues that would cause us to roll back.
If we did have to roll back we just change dns, instead of updaing a bunch of packages, etc.

You do make a good point that it adds another 'hop' in there and also makes us a dependency...

Yeah, I guess I was imagining that we would keep registry.fedoraproject.org for a while redirecting to quay.io and make sure there were not any big issues that would cause us to roll back. If we did have to roll back we just change dns, instead of updaing a bunch of packages, etc. You do make a good point that it adds another 'hop' in there and also makes us a dependency...
dustymabe commented 2024-04-30 15:52:11 +00:00
Copy link

Yeah, I guess I was imagining that we would keep registry.fedoraproject.org for a while redirecting to quay.io

I think it's fine to keep the redirector, but maybe we don't promote it? i.e. if people are using registry.fedoraproject.org then it would keep working.. but our docs and things all get updated to the new location?

> Yeah, I guess I was imagining that we would keep registry.fedoraproject.org for a while redirecting to quay.io I think it's fine to keep the redirector, but maybe we don't promote it? i.e. if people are using registry.fedoraproject.org then it would keep working.. but our docs and things all get updated to the new location?
rishi commented 2024-08-12 17:43:36 +00:00
Copy link

What's the latest thinking on this topic? Is there still a possibility that we might roll back away from quay.io and point registry.fedoraproject.org at something else?

I am asking because I want to figure out if Toolbx should start using the new quay.io URLs or stick to registry.fedoraproject.org.

What's the latest thinking on this topic? Is there still a possibility that we might roll back away from `quay.io` and point `registry.fedoraproject.org` at something else? I am asking because I want to figure out if Toolbx should start using the new `quay.io` URLs or stick to `registry.fedoraproject.org`.
kevin commented 2024-08-12 19:10:09 +00:00
Owner
Copy link

The plan is definitely still to go to quay.io, just too many fires burning to get to it.

We need to sort out flatpak stuff still.

If you want to go go quay.io it should be already in sync for toolbox, so go for it.

The plan is definitely still to go to quay.io, just too many fires burning to get to it. We need to sort out flatpak stuff still. If you want to go go quay.io it should be already in sync for toolbox, so go for it.
rishi commented 2024-08-12 19:13:01 +00:00
Copy link

The plan is definitely still to go to quay.io, just too many fires burning to get to it.

We need to sort out flatpak stuff still.

If you want to go go quay.io it should be already in sync for toolbox, so go for it.

Ok, understood. Thanks, Kevin.

> The plan is definitely still to go to quay.io, just too many fires burning to get to it. > > We need to sort out flatpak stuff still. > > If you want to go go quay.io it should be already in sync for toolbox, so go for it. Ok, understood. Thanks, Kevin.
zlopez commented 2025-01-07 11:49:40 +00:00
Author
Owner
Copy link

This is still waiting for the flatpak to migrate.

This is still waiting for the flatpak to migrate.
yselkowitz commented 2025-01-10 19:17:37 +00:00
Copy link

@otaylor is much more familiar with the delivery mechanics of flatpaks than I am, but not sure how much time he has for this right now. In his absence, I guess it will be up to me, but I'll need to be brought up to speed.

@otaylor is much more familiar with the delivery mechanics of flatpaks than I am, but not sure how much time he has for this right now. In his absence, I guess it will be up to me, but I'll need to be brought up to speed.
zlopez commented 2025-02-12 15:44:17 +00:00
Author
Owner
Copy link

I'm now trying to look at pointing the flatpak-indexer to quay.io and see if that works.

I'm now trying to look at pointing the flatpak-indexer to quay.io and see if that works.
zlopez commented 2025-03-06 08:59:11 +00:00
Author
Owner
Copy link

Finally got to it and found out where to obtain test data for tests. I will need to remove the ODCS part as this is causing for some reason issues on staging.

Finally got to it and found out where to obtain test data for tests. I will need to remove the ODCS part as this is causing for some reason issues on staging.
zlopez commented 2025-03-13 09:47:23 +00:00
Author
Owner
Copy link

Currently trying to get the flatpak-indexer running on my own machine, but I hit this issue and waiting for some solution https://github.com/fedora-infra/fedora-messaging/issues/440

Currently trying to get the flatpak-indexer running on my own machine, but I hit this issue and waiting for some solution https://github.com/fedora-infra/fedora-messaging/issues/440
smilner commented 2025-09-22 17:47:22 +00:00
Copy link

@zlopez are we still in process for this migration?

@zlopez are we still in process for this migration?
zlopez commented 2025-09-23 03:23:46 +00:00
Author
Owner
Copy link

@smilner I still have this on my TODO list, but currently have other priorities.

@smilner I still have this on my TODO list, but currently have other priorities.
zlopez commented 2025-10-20 13:21:35 +00:00
Author
Owner
Copy link

Metadata Update from @zlopez:

  • Issue tagged with: sprint-0
**Metadata Update from @zlopez**: - Issue tagged with: sprint-0
zlopez commented 2025-10-20 13:21:49 +00:00
Author
Owner
Copy link

Metadata Update from @zlopez:

  • Issue assigned to zlopez (was: t0xic0der)
**Metadata Update from @zlopez**: - Issue assigned to zlopez (was: t0xic0der)
rishi commented 2025-12-17 23:37:50 +00:00
Copy link

@pingou submitted a pull request to move Toolbx away from registry.fedoraproject.org URLs to their quay.io counterparts. I am curious if the registry.fedoraproject.org URLs are about to stop working soon. If so, we need to migrate toolbox(1) away from them on older distributions.

@pingou submitted a [pull request](https://github.com/containers/containertoolbx.org/pull/55) to move Toolbx away from `registry.fedoraproject.org` URLs to their `quay.io` counterparts. I am curious if the `registry.fedoraproject.org` URLs are about to stop working soon. If so, we need to migrate `toolbox(1)` away from them on older distributions.
zlopez commented 2025-12-18 08:26:05 +00:00
Author
Owner
Copy link

The last thing remaining is to point flatpak-indexer to quay.io, but not sure how long does that take.

So the registry.fedoraproject.org will not go away anytime soon.

The last thing remaining is to point `flatpak-indexer` to `quay.io`, but not sure how long does that take. So the `registry.fedoraproject.org` will not go away anytime soon.
rishi commented 2026-01-20 01:18:21 +00:00
Copy link

My apologies. I should have been more specific in my question.

Does it mean that registry.fedoraproject.org will be going away after flatpak-indexer is pointed at quay.io? Any rough idea of what soon looks like?

I am asking because we will have to migrate away from registry.fedoraproject.org on distributions as old as RHEL 8.10, where it's impossible to justify casual changes. So, we need some lead time to prepare for it.

I am wondering if we should already start at least migrating the code and the documentation in newer releases because this is a matter of time, or we can let the status quo continue for the foreseeable future.

My apologies. I should have been more specific in my question. Does it mean that `registry.fedoraproject.org` will be going away after `flatpak-indexer` is pointed at `quay.io`? Any rough idea of what *soon* looks like? I am asking because we will have to migrate away from `registry.fedoraproject.org` on distributions as old as RHEL 8.10, where it's impossible to justify casual changes. So, we need some lead time to prepare for it. I am wondering if we should already start at least migrating the code and the documentation in newer releases because this is a matter of time, or we can let the status quo continue for the foreseeable future.
zlopez commented 2026-01-20 10:14:55 +00:00
Author
Owner
Copy link

@kevin What is the plan for registry.fedoraproject.org after we migrate everything from it. Will it stay or do we want to decommission it?

@kevin What is the plan for registry.fedoraproject.org after we migrate everything from it. Will it stay or do we want to decommission it?
kevin commented 2026-01-20 23:33:41 +00:00
Owner
Copy link

My orig plan was to keep it around, but after talking with folks and thinking about it more, I think we want to retire it.
That said, there's no date currently, we need to sort out flatpaks and then anything else still left and only then we can set a retirement date.

So, I wouldn't stress over it. We also are happy to work with stakeholders on setting that date...

My orig plan was to keep it around, but after talking with folks and thinking about it more, I think we want to retire it. That said, there's no date currently, we need to sort out flatpaks and then anything else still left and only _then_ we can set a retirement date. So, I wouldn't stress over it. We also are happy to work with stakeholders on setting that date...
rishi commented 2026-01-22 13:36:32 +00:00
Copy link

Okay, thanks for clarifying that @zlopez & @kevin !

I will get started with migrating Toolbx away from registry.fedoraproject.org, and we'll see how the situation with old distributions shakes out.

Okay, thanks for clarifying that @zlopez & @kevin ! I will get started with migrating Toolbx away from `registry.fedoraproject.org`, and we'll see how the situation with old distributions shakes out.
siosm commented 2026-01-22 14:36:12 +00:00
Copy link

Hum, what changed here? Is keeping the redirect that much load on the infra?

If we really want to do this, we would have to update all the references to registry.fedoraproject.org in all the Containerfiles everywhere and make sure that the container stack redirects to the right place. That would be a massive change.

Hum, what changed here? Is keeping the redirect that much load on the infra? If we really want to do this, we would have to update all the references to `registry.fedoraproject.org` in all the Containerfiles everywhere and make sure that the container stack redirects to the right place. That would be a massive change.
kevin commented 2026-01-22 23:21:25 +00:00
Owner
Copy link

Sorry, perhaps I misunderstood the context here or did not explain myself well. :(

From my view nothing has changed.

I'm 100% fine keeping a redirect, but what I want is to no longer push to two places as we do now, and no longer maintain our own registry running docker-distribution, and no longer have...

/oci_registry   24T   20T  4.7T  81% /srv/registry

20TB and growing space used.

So, yes, the redirect/name will stay, but the backend/content I hope we can retire in favor of just having that once at quay.io.

Does that clarify?

Sorry, perhaps I misunderstood the context here or did not explain myself well. :( From my view nothing has changed. I'm 100% fine keeping a redirect, but what I want is to no longer push to two places as we do now, and no longer maintain our own registry running docker-distribution, and no longer have... ``` /oci_registry 24T 20T 4.7T 81% /srv/registry ``` 20TB and growing space used. So, yes, the redirect/name will stay, but the backend/content I hope we can retire in favor of just having that once at quay.io. Does that clarify?
siosm commented 2026-01-23 09:58:24 +00:00
Copy link

OK, thanks for the clarification. I'm on board with keeping just a redirect from registry.fedoraproject.org to quay.io and retiring our own hosted registry.

OK, thanks for the clarification. I'm on board with keeping just a redirect from `registry.fedoraproject.org` to `quay.io` and retiring our own hosted registry.
zlopez self-assigned this 2026-01-26 09:17:16 +00:00
zlopez commented 2026-01-29 12:55:45 +00:00
Author
Owner
Copy link

I did all the necessary changes to make flatpak-indexer work with latest upstream and quay.io. The problem is that the flatpak-indexer is just generating deltas and metadata for flatpaks. It doesn't do any uploading. So currently trying to discuss this with Fedora Flatpaks folks where this is being done as there isn't anything at all on quay.io.

I did all the necessary changes to make flatpak-indexer work with latest upstream and quay.io. The problem is that the flatpak-indexer is just generating deltas and metadata for flatpaks. It doesn't do any uploading. So currently trying to discuss this with Fedora Flatpaks folks where this is being done as there isn't anything at all on quay.io.
kevin commented 2026-01-29 21:21:18 +00:00
Owner
Copy link

Yeah, currently I think the flow is:

An update is submitted and goes to testing in bodhi and it syncs it from koji to candidate-registry.
When the update goes to stable it copies it from candidate-registry to registry.

So, I guess we need to teach bodhi to upload to quay.io (in addition to local registries)

Yeah, currently I think the flow is: An update is submitted and goes to testing in bodhi and it syncs it from koji to candidate-registry. When the update goes to stable it copies it from candidate-registry to registry. So, I guess we need to teach bodhi to upload to quay.io (in addition to local registries)
yselkowitz commented 2026-01-29 21:40:27 +00:00
Copy link

IIUC it is koji(-flatpak) that uploads to candidate-registry as part of the build. Bodhi then copies that image to registry as part of the update flow. registry.fp.o is the hard-coded default in bodhi but it is configurable per https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/base/templates/production.ini.j2#_209

IIUC it is koji(-flatpak) that uploads to candidate-registry as part of the build. Bodhi then copies that image to registry as part of the update flow. registry.fp.o is the hard-coded default in bodhi but it is configurable per https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/base/templates/production.ini.j2#_209
zlopez commented 2026-01-30 08:14:05 +00:00
Author
Owner
Copy link

I will start looking into it probably next week, as I understand we want it to upload to both registry.fedoraproject.org and quay.io for some transition period.

Do we want to move also candidate-registry to quay.io?

I will start looking into it probably next week, as I understand we want it to upload to both registry.fedoraproject.org and quay.io for some transition period. Do we want to move also candidate-registry to quay.io?
kevin commented 2026-01-30 23:03:08 +00:00
Owner
Copy link

Yes, we will need a place for bodhi to put things that are in updates-testing before moving to updates.
I think this should just be a slightly differently named repo in the fedora quay.io org.

Yes, we will need a place for bodhi to put things that are in updates-testing before moving to updates. I think this should just be a slightly differently named repo in the fedora quay.io org.
zlopez commented 2026-02-02 10:09:58 +00:00
Author
Owner
Copy link

I understand that, does flatpak-updates-testing sounds right?

I understand that, does `flatpak-updates-testing` sounds right?
yselkowitz commented 2026-02-02 15:10:50 +00:00
Copy link

All flatpaks go through bodhi so all tags have -updates. I don't think we need to include that in quay.io namespaces though.

All flatpaks go through bodhi so all tags have `-updates`. I don't think we need to include that in quay.io namespaces though.
kevin commented 2026-02-02 17:34:54 +00:00
Owner
Copy link

Yeah, I'd think 'flatpak-testing' would be fine.

Yeah, I'd think 'flatpak-testing' would be fine.
zlopez commented 2026-02-03 08:46:42 +00:00
Author
Owner
Copy link

Just to make it clear, do we need any change in https://pagure.io/koji-flatpak? From what I understand that just uploads to candidate-registry before bodhi uploads it to updates-testing . Or is updates-testing and candidate-registry the same place?

Just to make it clear, do we need any change in https://pagure.io/koji-flatpak? From what I understand that just uploads to `candidate-registry` before bodhi uploads it to `updates-testing` . Or is `updates-testing` and `candidate-registry` the same place?
yselkowitz commented 2026-02-03 13:20:54 +00:00
Copy link

IIUC koji-flatpak handles only the initial upload to candidate-registry during the build. Everything after that is handled by bodhi. So unless/until candidate-registry is changing, no changes to koji-flatpak should be necessary.

IIUC koji-flatpak handles only the initial upload to candidate-registry during the build. Everything after that is handled by bodhi. So unless/until candidate-registry is changing, no changes to koji-flatpak should be necessary.
kevin commented 2026-02-04 00:22:12 +00:00
Owner
Copy link

Well, thats something we should decide I guess.

We could:

  1. Just keep using/hosting our own candidate registry
  2. Setup a quay.io candidate registry and switch to using that

The advantage of 1 is that we are not dependent on another external service...
The advantage of 2 is that we are not required to keep our own registry around anymore.

Well, thats something we should decide I guess. We could: 1. Just keep using/hosting our own candidate registry 2. Setup a quay.io candidate registry and switch to using that The advantage of 1 is that we are not dependent on another external service... The advantage of 2 is that we are not required to keep our own registry around anymore.
yselkowitz commented 2026-02-04 01:19:01 +00:00
Copy link

Maybe switching candidate-registry should be considered (and tracked) separately, as it is not relevant to decommissioning registry?

Maybe switching candidate-registry should be considered (and tracked) separately, as it is not relevant to decommissioning registry?
zlopez commented 2026-02-04 08:29:36 +00:00
Author
Owner
Copy link

In that case, let's make candidate-registry separate issue and we can resolve it later.

I will start looking at Bodhi for the registry move.

In that case, let's make candidate-registry separate issue and we can resolve it later. I will start looking at Bodhi for the registry move.
zlopez commented 2026-02-10 14:36:46 +00:00
Author
Owner
Copy link

So I have PR for Bodhi in place, but I wonder how is the best way to test it. If it's better to just build bodhi package in infra-stg tag with the patch and test it on staging or just try to test it out in local development environment.

I will probably try to start with local environment and if that doesn't work, try the staging approach.

So I have [PR for Bodhi](https://github.com/fedora-infra/bodhi/pull/6077) in place, but I wonder how is the best way to test it. If it's better to just build bodhi package in infra-stg tag with the patch and test it on staging or just try to test it out in local development environment. I will probably try to start with local environment and if that doesn't work, try the staging approach.
zlopez commented 2026-02-12 08:54:26 +00:00
Author
Owner
Copy link

So I tried to test the changes in local dev environment, but to do that it needs to start a new compose which seems to not work in local dev environment.
I asked in #bodhi channel what is the best way to test the changes out as if they already have some process in place I don't want to mess with that.

So I tried to test the changes in local dev environment, but to do that it needs to start a new compose which seems to not work in local dev environment. I asked in #bodhi channel what is the best way to test the changes out as if they already have some process in place I don't want to mess with that.
zlopez commented 2026-02-16 09:57:43 +00:00
Author
Owner
Copy link

@mattia promised he will do deployment of my changes in staging to test it out. I will wait till that is in place to test it out.

@mattia promised he will do deployment of my changes in staging to test it out. I will wait till that is in place to test it out.
mattia commented 2026-02-16 17:02:50 +00:00
Copy link

@zlopez wrote in #11543 (comment):

@mattia promised he will do deployment of my changes in staging to test it out. I will wait till that is in place to test it out.

I was looking at deploy the PR yesterday, then I just left a comment on it. Shall we use 'quay.io/fedora/flatpak' for staging tests or is there a different namespace?
Since the setting is changing from string to a list, I need to fix the config at the same time I push the commit into staging, otherwise bodhi will crash.

@zlopez wrote in https://forge.fedoraproject.org/infra/tickets/issues/11543#issuecomment-392754: > @mattia promised he will do deployment of my changes in staging to test it out. I will wait till that is in place to test it out. I was looking at deploy the PR yesterday, then I just left a comment on it. Shall we use 'quay.io/fedora/flatpak' for staging tests or is there a different namespace? Since the setting is changing from string to a list, I need to fix the config at the same time I push the commit into staging, otherwise bodhi will crash.
zlopez commented 2026-02-17 08:31:59 +00:00
Author
Owner
Copy link

@mattia For staging we have quay.io/fedora-testingflatpak.

@mattia For staging we have `quay.io/fedora-testingflatpak`.
mattia commented 2026-02-17 17:15:30 +00:00
Copy link

@zlopez I have built the bodhi-server rpm with your changes in f43-infra-stg.
Now we need this config change to be pushed to ansible and rebuild the base image and deploy staging bodhi, but ansible is now being moved to the new forge, so I can't do that now. I'll look when the move is over.

@zlopez I have built the bodhi-server rpm with your changes in f43-infra-stg. Now we need [this](https://pagure.io/fork/mattia/fedora-infra/ansible/c/3489dcd36d6cf58d5fc76aae9c4e273db0a33285?branch=bodhi-stg-flatpak) config change to be pushed to ansible and rebuild the base image and deploy staging bodhi, but ansible is now being moved to the new forge, so I can't do that now. I'll look when the move is over.
👍 1
kevin commented 2026-02-17 22:51:37 +00:00
Owner
Copy link

Sorry about that.

Everything should be moved now, so you should be able to fork the forge repo and push your changes there and make a pr.

Sorry about that. Everything should be moved now, so you should be able to fork the forge repo and push your changes there and make a pr.
mattia commented 2026-02-18 15:11:52 +00:00
Copy link

The PR is ready, waiting for someone to merge it.

The [PR](https://forge.fedoraproject.org/infra/ansible/pulls/3121) is ready, waiting for someone to merge it.
zlopez commented 2026-02-18 15:55:50 +00:00
Author
Owner
Copy link

Merged.

Merged.
mattia commented 2026-02-18 18:28:34 +00:00
Copy link

I've pushed the patched bodhi into stg, happy testing! ;-)
Let me know if you need to synch the running db to a newer version, stg still has rawhide as F43...

I've pushed the patched bodhi into stg, happy testing! ;-) Let me know if you need to synch the running db to a newer version, stg still has rawhide as F43...
zlopez commented 2026-02-19 12:33:58 +00:00
Author
Owner
Copy link

@mattia You are right, the db needs to be updated. I installed the version you built in f43-infra-stg and updated the config on staging. But when I try to push F42F compose I just get that the packages are not in correct tag and looking at koji on staging, that is right.

Could you update the db on staging? I assume I will hit some issues with permissions for the user on quay.io, but that is what this testing is about.

@mattia You are right, the db needs to be updated. I installed the version you built in `f43-infra-stg` and updated the config on staging. But when I try to push `F42F` compose I just get that the packages are not in correct tag and looking at koji on staging, that is right. Could you update the db on staging? I assume I will hit some issues with permissions for the user on quay.io, but that is what this testing is about.
mattia commented 2026-02-19 17:42:22 +00:00
Copy link

@zlopez done, the staging db is now in synch with prod db as of today.

@zlopez done, the staging db is now in synch with prod db as of today.
ngompa commented 2026-02-19 17:43:35 +00:00
Copy link

Does this mean that registry.fp.o content will no longer be available to Syrians? We just unblocked them, but my understanding is that it's still blocked for Red Hat commercial properties (of which quay.io is one of them).

Does this mean that registry.fp.o content will no longer be available to Syrians? We _just_ unblocked them, but my understanding is that it's still blocked for Red Hat commercial properties (of which quay.io is one of them).
kevin commented 2026-02-19 20:06:32 +00:00
Owner
Copy link

@ngompa wrote in #11543 (comment):

Does this mean that registry.fp.o content will no longer be available to Syrians? We just unblocked them, but my understanding is that it's still blocked for Red Hat commercial properties (of which quay.io is one of them).

Perhaps @jflory7 could look into this ?

@ngompa wrote in https://forge.fedoraproject.org/infra/tickets/issues/11543#issuecomment-537203: > Does this mean that registry.fp.o content will no longer be available to Syrians? We _just_ unblocked them, but my understanding is that it's still blocked for Red Hat commercial properties (of which quay.io is one of them). Perhaps @jflory7 could look into this ?
zlopez commented 2026-02-23 09:02:44 +00:00
Author
Owner
Copy link

@mattia wrote in #11543 (comment):

@zlopez done, the staging db is now in synch with prod db as of today.

Thanks, will try it again today.

@mattia wrote in https://forge.fedoraproject.org/infra/tickets/issues/11543#issuecomment-537201: > @zlopez done, the staging db is now in synch with prod db as of today. Thanks, will try it again today.
zlopez commented 2026-02-23 13:24:40 +00:00
Author
Owner
Copy link

Encountered a problem when testing the bodhi on staging and wondering how to fix it. Each time I try to start a compose the builds are missing on koji.stg.fedoraproject.org (which is understandable as the bodhi was synced from prod) and the compose fails on that. @mattia How are you testing composes on staging?

Encountered a problem when testing the bodhi on staging and wondering how to fix it. Each time I try to start a compose the builds are missing on koji.stg.fedoraproject.org (which is understandable as the bodhi was synced from prod) and the compose fails on that. @mattia How are you testing composes on staging?
mattia commented 2026-02-23 17:49:07 +00:00
Copy link

@zlopez wrote in #11543 (comment):

How are you testing composes on staging?

I never did ;-)
The truth is that staging is mostly broken because it bases on the prod db which differs from what we have in stg koji. I ever only used stg to test some basic UI functionality.

@zlopez wrote in https://forge.fedoraproject.org/infra/tickets/issues/11543#issuecomment-541191: > How are you testing composes on staging? I never did ;-) The truth is that staging is mostly broken because it bases on the prod db which differs from what we have in stg koji. I ever only used stg to test some basic UI functionality.
zlopez commented 2026-02-24 10:43:40 +00:00
Author
Owner
Copy link

I wonder how to test the change than.

@mattia Any ideas?

Could it be possible to just try running the skopeo command with some testing flatpak?

I wonder how to test the change than. @mattia Any ideas? Could it be possible to just try running the skopeo command with some testing flatpak?
zlopez commented 2026-02-26 12:41:39 +00:00
Author
Owner
Copy link

Currently trying to run the skope command locally and it seems that this could be enough to test it out. Although I'm having some issues with authentication to quay.io, but that was expected.

Currently trying to run the skope command locally and it seems that this could be enough to test it out. Although I'm having some issues with authentication to quay.io, but that was expected.
zlopez commented 2026-02-26 14:05:13 +00:00
Author
Owner
Copy link

So I was able to test out the push to quay.io, but found few problems along the way:

  1. The quay.io doesn't allow nested organizations, so I can't really use https://quay.io/fedora-testing/flatpak, as that is only repository. I had to create a new organization for testing https://quay.io/organization/fedora-flatpak-testing?tab=repos. I already tested out uploading 0ad flatpak to this organization using skopeo copy -a --retry-times=10 docker://candidate-registry.fedoraproject.org/0ad:0.27.1-2 docker://quay.io/fedora-flatpak-testing/0ad:0.27.1-2 using bot account
  2. The repository have to be created separately for each flatpak, as the bot account has permissions per repository (which needs to be added for each newly created repository). This could be probably automated to run each time when new flatpak is added.
  3. The authentication credentials for quay.io bot needs to be saved in a location skopeo can find it, either adding --authfile parameter to skopeo or using default location, which I did. In my case I just used podman login, but that isn't persistent from what I was able to find about that.
So I was able to test out the push to quay.io, but found few problems along the way: 1. The quay.io doesn't allow nested organizations, so I can't really use https://quay.io/fedora-testing/flatpak, as that is only repository. I had to create a new organization for testing https://quay.io/organization/fedora-flatpak-testing?tab=repos. I already tested out uploading 0ad flatpak to this organization using `skopeo copy -a --retry-times=10 docker://candidate-registry.fedoraproject.org/0ad:0.27.1-2 docker://quay.io/fedora-flatpak-testing/0ad:0.27.1-2` using bot account 2. The repository have to be created separately for each flatpak, as the bot account has permissions per repository (which needs to be added for each newly created repository). This could be probably automated to run each time when new flatpak is added. 3. The authentication credentials for quay.io bot needs to be saved in a location skopeo can find it, either adding `--authfile` parameter to skopeo or using default location, which I did. In my case I just used `podman login`, but that isn't persistent from what I was able to find about that.
zlopez commented 2026-03-03 14:39:40 +00:00
Author
Owner
Copy link

Notes from today meeting with flatpak folks:

  1. Name of the organization on quay.io should be fedora-flatpaks and fedora-flatpaks-testing (for staging)
  2. There will be automation added for creating repositories in the organization and adding permissions to that repository to upload bot, when new repository will be requested and validated. This change will be done in scm_request_processor toddler
  3. We also discussed that we should probably move candidate-registry.fedoraproject.org as well to quay.io, but that will be future target and needs changes in koji-flatpak
Notes from today meeting with flatpak folks: 1. Name of the organization on quay.io should be `fedora-flatpaks` and `fedora-flatpaks-testing` (for staging) 2. There will be automation added for creating repositories in the organization and adding permissions to that repository to upload bot, when new repository will be requested and validated. This change will be done in `scm_request_processor` toddler 3. We also discussed that we should probably move `candidate-registry.fedoraproject.org` as well to quay.io, but that will be future target and needs changes in `koji-flatpak`
kevin commented 2026-03-03 19:55:35 +00:00
Owner
Copy link

Sounds reasonable to me. We should make sure we have admin/ownership of those in case we need to manage things later...

Sounds reasonable to me. We should make sure we have admin/ownership of those in case we need to manage things later...
👍 1
zlopez commented 2026-03-04 13:22:07 +00:00
Author
Owner
Copy link

So today I was able to create the fedora-flatpaks-testing organization and found out how to overcome the initial problems with the bot permissions and the inability to create repositories automatically. That means that we don't need to do any changes in scm_request_processor and just use the bot itself to create repositories.
I just need to create a script that will move everything currently hosted on registry.fedoraproject.org to new organization on quay.io. Will test that out on staging first. It will have to be ran only once, after that the repository will be automatically created when first build of the flatpak will be copied over from candidate-registry.

So today I was able to create the [fedora-flatpaks-testing organization](https://quay.io/organization/fedora-flatpaks-testing) and found out how to overcome the initial problems with the bot permissions and the inability to create repositories automatically. That means that we don't need to do any changes in `scm_request_processor` and just use the bot itself to create repositories. I just need to create a script that will move everything currently hosted on `registry.fedoraproject.org` to new organization on `quay.io`. Will test that out on staging first. It will have to be ran only once, after that the repository will be automatically created when first build of the flatpak will be copied over from `candidate-registry`.
yselkowitz commented 2026-03-04 16:22:53 +00:00
Copy link

There are certain containers in which we have been using namespaces, mostly runtimes, runtime extensions, and EOL-rebases. How would this work on quay.io?

There are certain containers in which we have been using namespaces, mostly runtimes, runtime extensions, and EOL-rebases. How would this work on quay.io?
kevin commented 2026-03-04 20:55:18 +00:00
Owner
Copy link

Also, I wonder... could we figure out a cleanup policy? ie have some way for quay.io to know whats no longer live content and can be removed? I guess that could be a more complicated sidetask.

Also, I wonder... could we figure out a cleanup policy? ie have some way for quay.io to know whats no longer live content and can be removed? I guess that could be a more complicated sidetask.
zlopez commented 2026-03-05 08:09:23 +00:00
Author
Owner
Copy link

@yselkowitz wrote in #11543 (comment):

There are certain containers in which we have been using namespaces, mostly runtimes, runtime extensions, and EOL-rebases. How would this work on quay.io?

As namespaces are managed as organizations on quay.io and I didn't found the way to create nested organization I think this could be a problem. Could we change that to simple quay.io/<organization>/<repository> structure?

@yselkowitz wrote in https://forge.fedoraproject.org/infra/tickets/issues/11543#issuecomment-570422: > There are certain containers in which we have been using namespaces, mostly runtimes, runtime extensions, and EOL-rebases. How would this work on quay.io? As namespaces are managed as organizations on quay.io and I didn't found the way to create nested organization I think this could be a problem. Could we change that to simple `quay.io/<organization>/<repository>` structure?
zlopez commented 2026-03-05 08:10:25 +00:00
Author
Owner
Copy link

@kevin wrote in #11543 (comment):

Also, I wonder... could we figure out a cleanup policy? ie have some way for quay.io to know whats no longer live content and can be removed? I guess that could be a more complicated sidetask.

I assume this could be resolved as separate issue. But it would be nice to have something like that in place.

@kevin wrote in https://forge.fedoraproject.org/infra/tickets/issues/11543#issuecomment-570459: > Also, I wonder... could we figure out a cleanup policy? ie have some way for quay.io to know whats no longer live content and can be removed? I guess that could be a more complicated sidetask. I assume this could be resolved as separate issue. But it would be nice to have something like that in place.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
announcement

   
anubis

Issues related to anubis

  
authentication

Authentication related issues

  
aws

Issues related to Amazon Web Services

  
backlog

Tasks that will take longer then ~4 hours to do

  
blocked

Issue is blocked

  
bodhi

Issues with Bodhi

  
ci

Continuous Integration

  
cloud

Items in FedoraInfraCloud or COmmunishift

  
communishift

issues/questions about os.edorainfracloud.org ( Community OpenShift)

  
copr

COPR system (run by other team)

  
database

Issues related to databases

  
day-to-day

These are small self contained tasks that are part of normal operations, but are async from sprint planning.

  
dc-move

Items related to datacenter move

  
deprecated

Tools which Infrastructure may not be able to fix

  
dev

Tasks requiring some dev work

  
discourse

outsourced tool

  
dns

Changes or problems with DNS

  
downloads

rsync,dl.fp.o,AWS,torrents

  
easyfix

   
epel

Issues relating to epel

  
firmitas

   
forgejo_migration

Request migration to the new forge

  
Gain
High
task that gets us a lot / is important / makes many people happy

  
Gain
Low
tasks that gets us little / isn't very important / makes only 1 person or few happy

  
Gain
Medium
task that gets us some / is somewhat important / makes some people happy

  
gitlab

   
greenwave

Issues with greenwave

  
hardware

Problem is with Fedora Infrastructure Owned/Leased Hardware

  
help wanted

   
high-trouble

task that is complex/long/difficult

  
koji

Issues with the build system

  
koschei

Items needing Koschei team

  
lists

issues with lists

  
low-trouble

task that is easy/short

  
medium-trouble

task that is medium complex / difficult

  
mirrorlists

Way to tell systems where downloads are

  
monitoring

   
Needs investigation

   
odcs

On Demand Compose Service issues

  
OpenShift

Issues with OpenShift

  
ops

ops problem now...

  
outage

   
packager_workflow_blocker

Blocks the packager workflow

  
pagure

Issues with pagure.io

  
permissions

Items which need permissions set in outside tools

  
Priority
Needs Review
Priority of Needs Review

  
Priority
Next Meeting
Priority of Next Meeting

  
Priority
🔥 URGENT 🔥
Priority of 🔥 URGENT 🔥

  
Priority
Waiting on Assignee
Priority of Waiting on Assignee

  
Priority
Waiting on External
Priority of Waiting on External

  
Priority
Waiting on Reporter
Priority of Waiting on Reporter

  
rabbitmq

issues with the message broker

  
release-monitoring

release-monitoring.org (Anitya)

  
releng

For problems which should be in the releng ticket system

  
request-for-resources

   
s390x

The secondary architecture hardware and problems related with it

  
security

   
SMTP

Email issues outside of lists (DMARC, SPF, aliases)

  
sprint-0

   
sprint-1

   
src.fp.o

Issues related to src.fedoraproject.org

  
staging

Issues in staging

  
unfreeze

Patches to be applied after freeze is lifted

  
waiverdb

Issues with waiverdb

  
websites-general

General items with a website focus

  
wiki

Issues with the Wiki

  
Backlog Status
Needs Review
Work items that have been created or updated but need review, refinement, or approval before they can be considered ready for sprint planning.

  
Backlog Status
Ready
Work items that have been reviewed, refined, and are ready to be committed to a sprint. These items have clear requirements and can be worked on immediately when capacity is available.

  
chore

Work that needs to be done but doesn't add new functionality or fix bugs. Maintenance tasks that keep the system running smoothly and the codebase clean.

  
documentation

Work focused on creating, updating, or improving documentation for users, developers, or system administrators.

  
points
01
A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  
points
02
This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  
points
03
Medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  
points
05
A significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  
points
08
Complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  
points
13
Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint and should be broken down.

  
Priority
High
This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  
Priority
Low
This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  
Priority
Medium
This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  
Sprint Status
Blocked
Work items that cannot progress due to external dependencies, blockers, or issues that need resolution.

  
Sprint Status
Done
Work items that have been completed, reviewed, and integrated. No further work is needed within the current sprint.

  
Sprint Status
In Progress
Work items currently being worked on by a team member. Active development, research, or implementation is happening.

  
Sprint Status
Review
Work items that are complete but need review, testing, or approval before being marked as done.

  
Sprint Status
To Do
Work items that are committed to the sprint but haven't been started yet. These items are ready to be picked up by team members.

  
Technical Debt

Work that addresses shortcuts, workarounds, or suboptimal implementations that were done previously to meet deadlines. These items improve code quality, maintainability, or performance without adding new features.

  
Work Item
Bug
Issues where the system is not working as intended or designed. Bugs represent deviations from expected behavior.

  
Work Item
Epic
Large initiatives that are broken down into multiple smaller work items (user stories, tasks, bugs). Epics represent significant features or projects that span multiple sprints.

  
Work Item
Spike
Time-boxed research, investigation, or proof-of-concept work to reduce uncertainty or explore solutions. Spikes help inform future development decisions.

  
Work Item
Task
Used to break down larger user stories into smaller, manageable implementation pieces. They focus on the specific technical steps needed to deliver the user story's value.

  
Work Item
User Story
User-facing features or functionality that can be framed from a user perspective, describing what someone wants to accomplish and why.

No labels
announcement
anubis
authentication
aws
backlog
blocked
bodhi
ci
cloud
communishift
copr
database
day-to-day
dc-move
deprecated
dev
discourse
dns
downloads
easyfix
epel
firmitas
forgejo_migration
Gain
High
Gain
Low
Gain
Medium
gitlab
greenwave
hardware
help wanted
high-trouble
koji
koschei
lists
low-trouble
medium-trouble
mirrorlists
monitoring
Needs investigation
odcs
OpenShift
ops
outage
packager_workflow_blocker
pagure
permissions
Priority
Needs Review
Priority
Next Meeting
Priority
🔥 URGENT 🔥
Priority
Waiting on Assignee
Priority
Waiting on External
Priority
Waiting on Reporter
rabbitmq
release-monitoring
releng
request-for-resources
s390x
security
SMTP
sprint-0
sprint-1
src.fp.o
staging
unfreeze
waiverdb
websites-general
wiki
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Current Sprint ( 2026-02-23 to 2026-03-08 )
Assignees
Clear assignees
No assignees
zlopez
12 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
infra/tickets#11543
No description provided.