View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000326||AlmaLinux-8||-OTHER||public||2022-11-11 20:01||2022-12-09 19:34|
|Summary||0000326: AlmaLinux 8.5 AMI disappeared? Please document removal schedule.|
We've been using AlmaLinux 8.5 as the base AMI for a cloudformation build. Starting today (or shortly earlier?), our build broke because the AMI is apparently no longer available.
The AMI ID is ami-0b4dad3b4322e5151 as was published on:
I guess I learned my lesson that we will need to host our own copies of AMIs; I had thought that we could trust the officially published AMIs to remain published.
Can you please document the schedule of upcoming removal dates alongside the list of AMI in the wiki? That would be good in order to set expectations.
|Steps To Reproduce||$ aws ec2 describe-images --region us-east-1 --image-ids=ami-0b4dad3b4322e5151|
|Tags||No tags attached.|
Unfortunately, we hit a "public AMI per region" limitation when try to publish 8.7 AMIs. Once resolve this limitation, we will build all older versions from the https://repo.almalinux.org/vault/
I asked this question on the AlmaLinux chat:
We get a bug report[^1] about the removal of the Amazon Machine Images of older versions which broke the reporter's build system. I can build them from the vault and re-publish again but I need to know:
* Use cases of using the older AMIs of AlmaLinux OS (8.3,8.4,8.5 and 8.6)
* If we decide to build them again which repos should be configured for the further DNF usage there, default(mirrors.almalinux.org) or https://repo.almalinux.org/vault/8.[3-6]/BaseOS/x86_64/os/
Let us know if someone uses the older AMIs as the reporter. Thanks!
Thank you for your responses. I filed this ticket mostly out of a desire for documentation of when AMI images are to be removed. The removal came as a surprise for me; I would have wanted to know up-front, when I found the AMI documentation, that older versions would eventually be removed. The important part for anybody who configures their build systems to use AMIs is that each configured AMI ID remain reachable. If the AlmaLinux foundation cannot retain older AMIs in perpetuity for practical reasons, that's understandable, but I think that should be made very clear up-front for anybody who searches and finds the published list of AMI IDs. A warning note on https://wiki.almalinux.org/cloud/AWS.html#community-amis would have been great for this.
My own use case for needing access to older AMI images will no longer apply, since we'll move to using copies of the AMIs hosted in our own AWS account, in order to be resilient going forward. Still, I'm happy to state my former use case.
In order to limit version sprawl across a large-ish fleet of diverse hosts, we don't use every new point release; rather, we select new releases as-needed and maintain older releases internally. AlmaLinux 8.5 was our most recent release in use (and our first use of AlmaLinux). We use our own locally-hosted yum repos, so the repo configuration built into the AMI doesn't matter for us, at least. I could imagine it would be a concern for other people, though. If having AMI for older releases with repos that work "out of the box" is desirable, then that would be a separate concern from what I am describing.
I filed a related ticket regarding an error when copying the AlmaLinux 8.7 AMI:
I would like to inform you that our public AMI limit requests finished successfully for the all regions excluding the new ones like ap-south-2, eu-south-2, eu-central-2 and me-central-1.
Thanks to public snapshot and current limit count, We can build older releases from the https://repo.almalinux.org/vault/ and update the wiki to make sure all versions is publicly available. I hope this updates is enough to resolve this bug.
Thanks. I personally no longer have a need for the older AMIs, since I scrambled to upgrade to 8.6 and then 8.7. Going forward, we host a local copy of the 8.7 AMI in our own AWS account.
I don't know if anybody else needs new builds of the older releases.
All I would ask for, at this point, is that _if_ existing AMIs are to be removed in the future, that the removal policy be posted alongside the listing of AMIs.
|2022-11-11 20:01||bugfood||New Issue|
|2022-11-13 22:24||lkhn||Assigned To||=> lkhn|
|2022-11-13 22:24||lkhn||Status||new => assigned|
|2022-11-13 22:34||lkhn||Note Added: 0000717|
|2022-11-14 14:31||lkhn||Note Added: 0000718|
|2022-11-14 17:30||bugfood||Note Added: 0000720|
|2022-11-15 18:17||bugfood||Note Added: 0000721|
|2022-12-09 16:54||lkhn||Note Added: 0000760|
|2022-12-09 17:55||bugfood||Note Added: 0000761|
|2022-12-09 19:34||lkhn||Status||assigned => resolved|
|2022-12-09 19:34||lkhn||Resolution||open => fixed|