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. _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
