infra/tickets
23
8
Fork 1
Code Issues 87 Projects Wiki Activity Actions

Cleaning script for communishift #11825

New issue
Closed
opened 2024-03-07 15:25:49 +00:00 by zlopez · 41 comments
zlopez commented 2024-03-07 15:25:49 +00:00
Owner
Copy link

Describe what you would like us to do:

As communishift is now up and announced we should create an ansible playbook to do the cleaning and update the post release docs, so it's not forgotten.

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

Not urgent, but sooner the better

# Describe what you would like us to do: ---- As communishift is now up and announced we should create an ansible playbook to do the cleaning and update the post release docs, so it's not forgotten. # When do you need this to be done by? (YYYY/MM/DD) ---- Not urgent, but sooner the better
seddik commented 2024-03-22 15:20:56 +00:00
Copy link

@zlopez do you have an example of cleaning the post release doc ?
Anyway, I can work on it , but need clarification from someone who worked on it .

@zlopez do you have an example of cleaning the post release doc ? Anyway, I can work on it , but need clarification from someone who worked on it .
zlopez commented 2024-03-25 10:00:59 +00:00
Author
Owner
Copy link

@kevin Do we have some docs for post release steps that needs to be done by Fedora Infra or is this part of release engineering guide?

@kevin Do we have some docs for post release steps that needs to be done by Fedora Infra or is this part of release engineering guide?
kevin commented 2024-03-25 22:42:04 +00:00
Owner
Copy link

Really the 'cleaning' here should just be 'oc delete project/$i' for all projects (that are not openshift-*/system ones)

Perhaps we could enhance the existing playbook for communishift to remove the projects instead of adding them, then you run that and remove them from the list in git.

We do have https://docs.fedoraproject.org/en-US/infra/release_guide/final_release/ but perhaps we could add a 'post final release' one?

Really the 'cleaning' here should just be 'oc delete project/$i' for all projects (that are not openshift-*/system ones) Perhaps we could enhance the existing playbook for communishift to remove the projects instead of adding them, then you run that and remove them from the list in git. We do have https://docs.fedoraproject.org/en-US/infra/release_guide/final_release/ but perhaps we could add a 'post final release' one?
zlopez commented 2024-03-26 10:32:27 +00:00
Author
Owner
Copy link

@kevin I agree that adding post final release guide makes sense as this shouldn't be bothering people during release.

@kevin I agree that adding `post final release` guide makes sense as this shouldn't be bothering people during release.
zlopez commented 2024-06-18 11:50:06 +00:00
Author
Owner
Copy link

After DevConf.CZ and discussion happening there, I would like to add that part of this should be also some announcements sent to contacts for communishift projects that will let owners know the post release cleaning is coming.
This could happen a month before the release and then again 14 days, so owners have time to react.

After DevConf.CZ and discussion happening there, I would like to add that part of this should be also some announcements sent to contacts for communishift projects that will let owners know the post release cleaning is coming. This could happen a month before the release and then again 14 days, so owners have time to react.
dkirwan commented 2024-06-18 14:52:58 +00:00
Member
Copy link

Metadata Update from @dkirwan:

  • Issue assigned to dkirwan
**Metadata Update from @dkirwan**: - Issue assigned to dkirwan
moralcode commented 2024-07-11 17:53:08 +00:00
Copy link

I saw this get built by someone at my university some years back, so maybe its not too hard to adapt to the communishift cluster and infra: https://github.com/WillNilges/ShelfLife

looks like it was also built for an openshift cluster and i believe it was also set up to notify people via email when their stuff was about to expire.

I saw this get built by someone at my university some years back, so maybe its not too hard to adapt to the communishift cluster and infra: https://github.com/WillNilges/ShelfLife looks like it was also built for an openshift cluster and i believe it was also set up to notify people via email when their stuff was about to expire.
moralcode commented 2024-07-11 17:56:19 +00:00
Copy link

As far as scheduling when things get deleted, i think it may be nice to reuse the same date as the EOL-ing of F[N-2] (so 2024-11-12 for F41, see https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html) to give users an extra heads up well in advance (i.e. the user docs could document that the deletion date is around the time of the EOLing of the fedora release).

That said, an arbitrary date like that that may change every cycle may be a moving target thats hard to pin down and automate things against.

As far as scheduling when things get deleted, i think it may be nice to reuse the same date as the EOL-ing of F[N-2] (so 2024-11-12 for F41, see https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html) to give users an extra heads up well in advance (i.e. the user docs could document that the deletion date is around the time of the EOLing of the fedora release). That said, an arbitrary date like that that may change every cycle may be a moving target thats hard to pin down and automate things against.
zlopez commented 2024-07-29 13:17:46 +00:00
Author
Owner
Copy link

Metadata Update from @zlopez:

  • Issue tagged with: communishift
**Metadata Update from @zlopez**: - Issue tagged with: communishift
zlopez commented 2024-07-29 13:22:02 +00:00
Author
Owner
Copy link

We will have this as part of Fedora Infra hackfest to discuss when and how to delete the project. The delete with EOL date makes sense, but how much before it we should notify owners of the project. And all of this should be documented as well.

For now we have two requests for not deleting the projects:

We will have this as part of Fedora Infra hackfest to discuss when and how to delete the project. The delete with EOL date makes sense, but how much before it we should notify owners of the project. And all of this should be documented as well. For now we have two requests for not deleting the projects: * [communishift-log-detective](https://pagure.io/fedora-infrastructure/issue/11868) * [communishift-fedora-review-service](https://pagure.io/fedora-infrastructure/issue/11814)
zlopez commented 2024-10-17 16:38:31 +00:00
Author
Owner
Copy link

As Fedora 39 EOL is coming near, we should move this forward.

@dkirwan Did you have time to work on this?

As Fedora 39 EOL is coming near, we should move this forward. @dkirwan Did you have time to work on this?
dkirwan commented 2024-10-18 12:55:05 +00:00
Member
Copy link

@zlopez when this is needed can you assign this task of clean the cluster? I'll go through what ever is involved manually, add an ansible task and gather all the moving parts into a SOP.

@zlopez when this is needed can you assign this task of clean the cluster? I'll go through what ever is involved manually, add an ansible task and gather all the moving parts into a SOP.
zlopez commented 2024-10-18 14:21:25 +00:00
Author
Owner
Copy link

@dkirwan What task do you mean?

The SOP would be great, we also need to let owners of the projects know about that each cycle of cleaning. So they can react in time.

@dkirwan What task do you mean? The SOP would be great, we also need to let owners of the projects know about that each cycle of cleaning. So they can react in time.
dkirwan commented 2024-11-11 09:01:24 +00:00
Member
Copy link

Looking at adding a playbook to retrieve project admin users emails from each project then send them a notification email about incoming project deletions.

Considering the following template:

to: "{{ item.value.comma_separated_admin_email_list}}"
from: "admin@fedoraproject.org"
subject: "Fedora Communishift Notification: {{ item.value.name }}"
body: "Dear Administrator,

This is a reminder that the Communishift project {{ item.value.name }} will be deleted during the Fedora post release process. Please ensure you have a backup of any important configuration or data from your project.

To request an exemption for project deletion please open a ticket here: https://pagure.io/fedora-infrastructure/issues"
Looking at adding a playbook to retrieve project admin users emails from each project then send them a notification email about incoming project deletions. Considering the following template: ``` to: "{{ item.value.comma_separated_admin_email_list}}" from: "admin@fedoraproject.org" subject: "Fedora Communishift Notification: {{ item.value.name }}" body: "Dear Administrator, This is a reminder that the Communishift project {{ item.value.name }} will be deleted during the Fedora post release process. Please ensure you have a backup of any important configuration or data from your project. To request an exemption for project deletion please open a ticket here: https://pagure.io/fedora-infrastructure/issues" ```
kevin commented 2024-11-11 21:49:30 +00:00
Owner
Copy link

Might make it more discoverable when the date is?

I guess we decided to do this when EOLing the old fedora release. So, in this case it's 2024-11-26 that F39 goes eol. We could put in the date, or just try and say something like 'at the same time the oldest fedora is retired (1 month after a new fedora release)" or something?

I also wonder, perhaps we should make a ticket in advance and just tell people to add to that one ticket instead of filing a bunch of them?
("To request an exemption for project deletion please add your request to https://pagure.io/fedora-infrastructure/issue/12345678")

Otherwise looks good.

Might make it more discoverable when the date is? I guess we decided to do this when EOLing the old fedora release. So, in this case it's 2024-11-26 that F39 goes eol. We could put in the date, or just try and say something like 'at the same time the oldest fedora is retired (1 month after a new fedora release)" or something? I also wonder, perhaps we should make a ticket in advance and just tell people to add to that one ticket instead of filing a bunch of them? ("To request an exemption for project deletion please add your request to https://pagure.io/fedora-infrastructure/issue/12345678") Otherwise looks good.
zlopez commented 2024-11-12 12:46:55 +00:00
Author
Owner
Copy link

I like the idea of having one ticket created in advance, we can close it once the cleanup is done.

I like the idea of having one ticket created in advance, we can close it once the cleanup is done.
dkirwan commented 2024-11-21 16:21:27 +00:00
Member
Copy link

Screenshot_from_2024-11-21_16-09-45.png

Updated the communishfit role, and added a new playbook. Can retrieve the communishift projects plus the email addresses of the admins from fasjson. Also have task that can then send the email template in ansible.

Final piece of work to update the To field to point at these admin email addresses.

[![Screenshot_from_2024-11-21_16-09-45.png](/fedora-infrastructure/issue/raw/files/bbbb7cb2d9a361549622783b40601d1ae073bf23d1bd398636dd2e950f621127-Screenshot_from_2024-11-21_16-09-45.png)](/fedora-infrastructure/issue/raw/files/bbbb7cb2d9a361549622783b40601d1ae073bf23d1bd398636dd2e950f621127-Screenshot_from_2024-11-21_16-09-45.png) Updated the communishfit role, and added a new playbook. Can retrieve the communishift projects plus the email addresses of the admins from fasjson. Also have task that can then send the email template in ansible. Final piece of work to update the To field to point at these admin email addresses.
kevin commented 2024-11-22 19:41:08 +00:00
Owner
Copy link

Awesome. I think at this point we should give them more time (since next week is a holiday in the us and not much notice), but perhaps sometime in mid december?

Awesome. I think at this point we should give them more time (since next week is a holiday in the us and not much notice), but perhaps sometime in mid december?
kevin commented 2025-04-21 18:57:35 +00:00
Owner
Copy link

Did anything happen here?

I guess we should re-notify people again and see what would be cleaned up?

Did anything happen here? I guess we should re-notify people again and see what would be cleaned up?
dkirwan commented 2025-05-12 11:26:27 +00:00
Member
Copy link

From memory only a single tenant responded in anyway to request the projects be exempted, might need to rethink the auto deleting part entirely. Would feel happier if that was done manually, fairly easy to just oc delete project etc.. especially as it will require extra steps such as disabling/removing FAS groups as not sure disabling them will prevent fasjson returning the data, must test that.

Can do another run of the notifications steps, just let me know when we want to do the actual deleting steps, I can make sure everything is properly documented in an SOP.

From memory only a single tenant responded in anyway to request the projects be exempted, might need to rethink the auto deleting part entirely. Would feel happier if that was done manually, fairly easy to just oc delete project etc.. especially as it will require extra steps such as disabling/removing FAS groups as not sure disabling them will prevent fasjson returning the data, must test that. Can do another run of the notifications steps, just let me know when we want to do the actual deleting steps, I can make sure everything is properly documented in an SOP.
zlopez commented 2025-05-12 13:20:08 +00:00
Author
Owner
Copy link

The F42 release is already out and F40 EOL, so we can do the delete anytime.

Do I understand it correctly that only one tenant didn't want the project to be deleted?

The F42 release is already out and F40 EOL, so we can do the delete anytime. Do I understand it correctly that only one tenant didn't want the project to be deleted?
dkirwan commented 2025-05-12 14:27:45 +00:00
Member
Copy link

Yeah only one tenant responded, that might mean the rest marked the reminder email read and never actually read it/saw it.

Perhaps before deleting, shut any services contained within down, and see if anyone complains?

Yeah only one tenant responded, that might mean the rest marked the reminder email read and never actually read it/saw it. Perhaps before deleting, shut any services contained within down, and see if anyone complains?
zlopez commented 2025-05-12 14:45:30 +00:00
Author
Owner
Copy link

Doing a scream test is not a bad idea. Let's disable the project for a week and see if there will be any response first and then delete it.

We can make that part of the official process, so there is still a time for folks to reach out.

Doing a scream test is not a bad idea. Let's disable the project for a week and see if there will be any response first and then delete it. We can make that part of the official process, so there is still a time for folks to reach out.
frostyx commented 2025-05-12 20:21:48 +00:00
Copy link

Perhaps before deleting, shut any services contained within down, and see if anyone complains?

This is a really good idea. Please make this a part of the official process.

Do I understand it correctly that only one tenant didn't want the project to be deleted?

Not sure if there is a public list of exceptions somewhere in playbooks and not sure if the one tenant was me. So please, just don't remove these two:

> Perhaps before deleting, shut any services contained within down, and see if anyone complains? This is a really good idea. Please make this a part of the official process. > Do I understand it correctly that only one tenant didn't want the project to be deleted? Not sure if there is a public list of exceptions somewhere in playbooks and not sure if the one tenant was me. So please, just don't remove these two: - https://pagure.io/fedora-infrastructure/issue/11868 - https://pagure.io/fedora-infrastructure/issue/11814
kevin commented 2025-05-12 23:15:51 +00:00
Owner
Copy link

At this point I think re-notifying people might be in order... but yeah, if we have a way to just 'suspend' a project for a while where we could easily just re-enable it if someone comes asking could be a better way to do things.

At this point I think re-notifying people might be in order... but yeah, if we have a way to just 'suspend' a project for a while where we could easily just re-enable it if someone comes asking could be a better way to do things.
dkirwan commented 2025-05-14 13:15:48 +00:00
Member
Copy link

https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/all#_42

@frostyx Yes we mark the fact projects should not be deleted here. I believe both your projects are marked correctly.

Not sure if there is a public list of exceptions somewhere in playbooks and not sure if the one tenant was me. So please, just don't remove these two:

https://pagure.io/fedora-infra/ansible/blob/main/f/inventory/group_vars/all#_42 @frostyx Yes we mark the fact projects should not be deleted here. I believe both your projects are marked correctly. > Not sure if there is a public list of exceptions somewhere in playbooks and not sure if the one tenant was me. So please, just don't remove these two: > > - https://pagure.io/fedora-infrastructure/issue/11868 > - https://pagure.io/fedora-infrastructure/issue/11814
dkirwan commented 2025-12-18 16:06:30 +00:00
Member
Copy link

Finally had a minute to revisit this, since there was little to no engagement from the communishift admins the last time the emails were sent out.. i figure most are filtering emails from the admin address, so I want to send an email to the infra list and BCC the administrators. Hopefully they will pay attention to mails on the infra list.

Looks like the emails get filtered though.. can we white list them or should I look at a different way to send these notifications?

Finally had a minute to revisit this, since there was little to no engagement from the communishift admins the last time the emails were sent out.. i figure most are filtering emails from the admin address, so I want to send an email to the infra list and BCC the administrators. Hopefully they will pay attention to mails on the infra list. Looks like the emails get filtered though.. can we white list them or should I look at a different way to send these notifications?
zlopez commented 2026-03-26 17:39:51 +00:00
Author
Owner
Copy link

@dkirwan Do you mean that they have filters in place that filter out the e-mails? Or what do you want to whitelist here?

@dkirwan Do you mean that they have filters in place that filter out the e-mails? Or what do you want to whitelist here?
dkirwan commented 2026-03-30 08:36:53 +00:00
Member
Copy link

So I need to be able to send emails to the infra list from the batcave.. ill look this back up and get the address tehy are coming from.

Seems our users are ignoring the ones I am sending directly as I had only one person respond/engage, and I dont want to be in the situation where I am tracking people down manually otherwise we should just skip this entirely and do that instead.

So I need to be able to send emails to the infra list from the batcave.. ill look this back up and get the address tehy are coming from. Seems our users are ignoring the ones I am sending directly as I had only one person respond/engage, and I dont want to be in the situation where I am tracking people down manually otherwise we should just skip this entirely and do that instead.
zlopez commented 2026-03-30 10:33:07 +00:00
Author
Owner
Copy link

Hm, I thought that sending e-mails from batcave to infrastructure@lists.fedoraproject.org should be possible, but it could be problem that the sender is not subscribed to the list.

From which e-mail address are the mails sent?

Hm, I thought that sending e-mails from batcave to infrastructure@lists.fedoraproject.org should be possible, but it could be problem that the sender is not subscribed to the list. From which e-mail address are the mails sent?
dkirwan commented 2026-04-08 10:29:15 +00:00
Member
Copy link

I think its this address.. admin at fedoraproject.org

I think its this address.. admin at fedoraproject.org
zlopez commented 2026-04-08 11:51:19 +00:00
Author
Owner
Copy link

I'm not sure if we want to add admin@fedoraproject.org to infrastructure@lists.fedoraproject.org as it will add a lot of e-mails to admins inbox. @kevin What do you think about this?

I'm not sure if we want to add `admin@fedoraproject.org` to `infrastructure@lists.fedoraproject.org` as it will add a lot of e-mails to admins inbox. @kevin What do you think about this?
kevin commented 2026-04-08 16:30:48 +00:00
Owner
Copy link

We can subscribe it and set it to 'no mail' so it doesn't get any of the emails.
Or set as a 'non member' address thats allowed to post.

We can subscribe it and set it to 'no mail' so it doesn't get any of the emails. Or set as a 'non member' address thats allowed to post.
zlopez commented 2026-04-09 08:00:49 +00:00
Author
Owner
Copy link

Let me do that then, I didn't know that there is this option.

Let me do that then, I didn't know that there is this option.
zlopez commented 2026-04-09 08:07:18 +00:00
Author
Owner
Copy link

During that I found out that the admin@fedoraproject.org is already a nonmember on the list.
image

@dkirwan Maybe it wasn't there last time you tried to sent the e-mail. Could you try it now?

During that I found out that the `admin@fedoraproject.org` is already a nonmember on the list. ![image](/attachments/301c1dca-0077-47aa-9bab-9781ad0b7f71) @dkirwan Maybe it wasn't there last time you tried to sent the e-mail. Could you try it now?
image.png
28 KiB
zlopez commented 2026-04-15 12:32:13 +00:00
Author
Owner
Copy link

It seems that the admin@fedoraproject.org needs to be a member, otherwise it couldn't send e-mails. So I changed the settings for the user to accept any e-mail sent from that user. @dkirwan Could you test it now?

It seems that the `admin@fedoraproject.org` needs to be a member, otherwise it couldn't send e-mails. So I changed the settings for the user to accept any e-mail sent from that user. @dkirwan Could you test it now?
dkirwan commented 2026-04-15 12:38:11 +00:00
Member
Copy link

Seems like that fixed it @zlopez ! Can you check the emails coming in the infra list and see what we think..

Seems like that fixed it @zlopez ! Can you check the emails coming in the infra list and see what we think..
dkirwan commented 2026-04-15 12:57:48 +00:00
Member
Copy link

Spoke with @zlopez we will give another week for tenants to respond. Then in one week will start disabling projects (2026-04-22), and 2 weeks after that date start to delete them (2026-05-06).

Spoke with @zlopez we will give another week for tenants to respond. Then in one week will start disabling projects (2026-04-22), and 2 weeks after that date start to delete them (2026-05-06).
dkirwan commented 2026-05-01 12:03:30 +00:00
Member
Copy link

Sent out another reminder email.

And disabled a number of projects.

✅ OK to delete: communishift-avant
✅ OK to delete: communishift-commops-analytics
✅ OK to delete: communishift-commops-datanom
✅ OK to delete: communishift-discoursepolls
✅ OK to delete: communishift-eventbot
✅ OK to delete: communishift-forgejo
✅ OK to delete: communishift-fossology
✅ OK to delete: communishift-gitlabce
✅ OK to delete: communishift-jitsi
✅ OK to delete: communishift-lightspeed-build
✅ OK to delete: communishift-mattdm
✅ OK to delete: communishift-metrics
✅ OK to delete: communishift-ocm
✅ OK to delete: communishift-openscanhub
✅ OK to delete: communishift-planet
✅ OK to delete: communishift-standupbot

Will remove these next week if no one screams.

Sent out another reminder email. And disabled a number of projects. ``` ✅ OK to delete: communishift-avant ✅ OK to delete: communishift-commops-analytics ✅ OK to delete: communishift-commops-datanom ✅ OK to delete: communishift-discoursepolls ✅ OK to delete: communishift-eventbot ✅ OK to delete: communishift-forgejo ✅ OK to delete: communishift-fossology ✅ OK to delete: communishift-gitlabce ✅ OK to delete: communishift-jitsi ✅ OK to delete: communishift-lightspeed-build ✅ OK to delete: communishift-mattdm ✅ OK to delete: communishift-metrics ✅ OK to delete: communishift-ocm ✅ OK to delete: communishift-openscanhub ✅ OK to delete: communishift-planet ✅ OK to delete: communishift-standupbot ``` Will remove these next week if no one screams.
dkirwan commented 2026-05-11 11:03:22 +00:00
Member
Copy link
Exemption added for: communishift-standupbot

Moving ahead with deleting these remaining projects:

✅ OK to delete: communishift-avant
✅ OK to delete: communishift-commops-analytics
✅ OK to delete: communishift-commops-datanom
✅ OK to delete: communishift-discoursepolls
✅ OK to delete: communishift-eventbot
✅ OK to delete: communishift-forgejo
✅ OK to delete: communishift-fossology
✅ OK to delete: communishift-gitlabce
✅ OK to delete: communishift-jitsi
✅ OK to delete: communishift-lightspeed-build
✅ OK to delete: communishift-mattdm
✅ OK to delete: communishift-metrics
✅ OK to delete: communishift-ocm
✅ OK to delete: communishift-openscanhub
✅ OK to delete: communishift-planet
``` Exemption added for: communishift-standupbot ``` Moving ahead with deleting these remaining projects: ``` ✅ OK to delete: communishift-avant ✅ OK to delete: communishift-commops-analytics ✅ OK to delete: communishift-commops-datanom ✅ OK to delete: communishift-discoursepolls ✅ OK to delete: communishift-eventbot ✅ OK to delete: communishift-forgejo ✅ OK to delete: communishift-fossology ✅ OK to delete: communishift-gitlabce ✅ OK to delete: communishift-jitsi ✅ OK to delete: communishift-lightspeed-build ✅ OK to delete: communishift-mattdm ✅ OK to delete: communishift-metrics ✅ OK to delete: communishift-ocm ✅ OK to delete: communishift-openscanhub ✅ OK to delete: communishift-planet ```
dkirwan commented 2026-05-11 12:34:13 +00:00
Member
Copy link

Post cleanup projects:

communishift-admins                                               Active
communishift-authorization-operator                               Active
communishift-dev-test                                             Active
communishift-fedora-coreos-ai-helpers                             Active
communishift-fedora-review-service                                Active
communishift-log-detective                                        Active
communishift-standupbot                                           Active
communishift-weekly-bootc                                         Active

SOP updated https://docs.fedoraproject.org/en-US/infra/sysadmin_sops/communishift_cleanup_script/

Post cleanup projects: ``` communishift-admins Active communishift-authorization-operator Active communishift-dev-test Active communishift-fedora-coreos-ai-helpers Active communishift-fedora-review-service Active communishift-log-detective Active communishift-standupbot Active communishift-weekly-bootc Active ``` SOP updated https://docs.fedoraproject.org/en-US/infra/sysadmin_sops/communishift_cleanup_script/
👍 1
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
Assignees
Clear assignees
No assignees
6 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#11825
No description provided.