Hi,
I just created ticket https://pagure.io/fedora-infrastructure/issue/12237 (for awareness/visibility), itself a downstream ticket of https://issues.redhat.com/browse/CS-2561)
It seems that we reached the AWS quota wrt number of shared AMI. I had a *very* quick look at the regions mentioned in ticket and I see Fedora CoreOS (mainly) has very old AMI that don't seem to be deleted/cleaned up (or just unshared at least)
Is there a way to ensure that all team pushing AMI to AWS various regions would also have a max of shared images, and also unshare (or better, remove entirely as there is another quota for number of AMI images per account) such AMIs ?
To unblock CentOS Stream deliveries (as I got confirmation it's impacting also Stream 9 images now), I intent (if no reaction in this thread and/or infra ticket) to just delete the very old Fedora CoreOS AMIs next Monday
Hi Fabian,
I'm for cleaning up the old releases and have some kind of job that will do this periodically in the future.
Michal
On 11. 10. 24 11:31, Fabian Arrotin via infrastructure wrote:
Hi,
I just created ticket https://pagure.io/fedora-infrastructure/issue/12237 (for awareness/visibility), itself a downstream ticket of https://issues.redhat.com/browse/CS-2561)
It seems that we reached the AWS quota wrt number of shared AMI. I had a *very* quick look at the regions mentioned in ticket and I see Fedora CoreOS (mainly) has very old AMI that don't seem to be deleted/cleaned up (or just unshared at least)
Is there a way to ensure that all team pushing AMI to AWS various regions would also have a max of shared images, and also unshare (or better, remove entirely as there is another quota for number of AMI images per account) such AMIs ?
To unblock CentOS Stream deliveries (as I got confirmation it's impacting also Stream 9 images now), I intent (if no reaction in this thread and/or infra ticket) to just delete the very old Fedora CoreOS AMIs next Monday
On Fri, Oct 11, 2024 at 11:31:43AM +0200, Fabian Arrotin via infrastructure wrote:
Hi,
I just created ticket https://pagure.io/fedora-infrastructure/issue/12237 (for awareness/visibility), itself a downstream ticket of https://issues.redhat.com/browse/CS-2561)
It seems that we reached the AWS quota wrt number of shared AMI. I had a *very* quick look at the regions mentioned in ticket and I see Fedora CoreOS (mainly) has very old AMI that don't seem to be deleted/cleaned up (or just unshared at least)
Is there a way to ensure that all team pushing AMI to AWS various regions would also have a max of shared images, and also unshare (or better, remove entirely as there is another quota for number of AMI images per account) such AMIs ?
Not that I know of... but the limit is somewhat artificial.
To unblock CentOS Stream deliveries (as I got confirmation it's impacting also Stream 9 images now), I intent (if no reaction in this thread and/or infra ticket) to just delete the very old Fedora CoreOS AMIs next Monday
David Duncan is increasing our limit now on the affected regions. That should unblock you and we can talk to coreos folks about how best to lifecycle/clean up their images.
kevin
I had a *very* quick look at the regions mentioned in ticket and I see Fedora CoreOS (mainly) has very old AMI that don't seem to be deleted/cleaned up (or just unshared at least)
Update for pruning in Fedora CoreOS: We’ve implemented garbage collection for cloud uploads (AWS AMIs, Snapshots, and GCP images) which would clean up those resources periodically every time we run a release. So far, we have started running the GC on mechanical streams but will be expanded to all the production streams soon which would clean up all the old AMIs. Also, could you not delete our images (assuming the quota is increased for now) since we're going to be doing it soon:) Thanks.
Dne 15. 10. 24 v 7:51 odp. Gursewak Singh via infrastructure napsal(a):
Also, could you not delete our images (assuming the quota is increased for now) since we're going to be doing it soon:)
If that is to me... I do not delete any resourece that belong to somebody. I.e. if that has FedoraGroup tag, I leave it as it is. No matter how old it is.
infrastructure@lists.fedoraproject.org