Cloud image lifetimes

[Ryan Brown]

On 03/18/2015 06:38 PM, David Gay wrote:
> Greetings!
> 
> We sort of ran out of time in today's Cloud WG meeting, but I did want to ask:
> 
> What are your thoughts on AMI lifetimes? That is to say, how long should EC2 AMIs exist before they're deleted? A few points to consider:
> 
> - AMIs only cost us for storage, so it's not a *huge* cost to maintain a public AMI
>   - At the same time, there are a lot of AMIs, since we build 2-4 per AWS region per build, and that number is growing
>     - There are 9 regions now, and we have 2 virtualization types, and 2 volume types, as well (9 regions * 2 * 2 = 36 AMIs per Base image build, 18 for Atomic builds (since they are only available in HVM format))
>       - This total number will only grow larger as we add instance-store AMIs, and so on
> - This isn't even taking into account any costs we'll have once we secure a deal with other providers like HP, Rackspace, and GCE, to maintain public images on their services
> 
> I propose we have some sort of discussion regarding how long cloud image builds should be available on services like AWS. I suspect this will resolve to having different lifetimes for scratch, test, RC, final, and maybe other build types.

In my experience, folks expect AMIs to stick around for a long time. AMI
IDs work their way into all sorts of places (scripts, ansible playbooks,
CloudFormation templates, and a zillion others) so I think that deleting
an AMI before the end of the supported lifetime of a release would make
people sad*.

I think it's reasonable to only offer that support for release AMIs, and
scratch/test/RC/etc AMIs would have to have a shorter lifetime.

My (very rough) calculations put the cost of storing 4 AMIs per region
at around $5/month, so each "final" AMI built will cost $5 * 13-16
months, or $65-$80. Not expensive, but not exactly free. Costs will, of
course, vary for other cloud providers.

Of course, there's no replacement for checking the metrics to see what
folks actually use.

* or angry, because their scripts will be broken

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.