Cloud image lifetimes

[David Gay]

Cool, thanks for the input everyone. A short summary of what's been discussed:

1. Everyone seems to agree that we should hope to get usage data from AWS, but as Dennis mentioned (and I expect), there isn't any usage data available for AMIs. If there is such a console, I've never seen one.

2. Q: "If a user spins up an AMI and then it's deleted by the provider, do they
still have their instance(s) or do they lose the ability to create new
images?"
  A: "The instances they already started would still run and be available, but
  they wouldn't be able to spin up anything new. If creating/killing
  instances is something they do a lot (autoscaling groups, worker farms,
  etc) then that could hose them just as surely as killing their existing
  instances."

3. We should probably look into how other projects handle their AMIs. I think the consensus here though is that whatever lifetime we have for releases, the alpha, beta, TC, RC, and other testing builds can -- and should -- be safely eliminated after the release. There's no good reason I can think of that someone would yell at us for deleting a test build AMI of a release that's already happened.

4. Anyone have an opinion on jzb wondering if we should run this by FESCo?

5. Regarding this exchange:

"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."
  "your math is off, there should only be 9 Atomic as we only build it for x86_64
  where we build the base for i386 and x86_64  so you have two arches by 2 image
  types by 9 regions"

Whatever the costs will be per AMI, I can tell you that what I've heard from people in the cloud WG is that we want a number of different AMIs *per build*. A new build currently results in 6 AMIs: 2 for atomic (standard + gp2) and 4 for base (standard + gp2, both for HVM and paravirtual virtualization). I spoke with gholms some time back and I think we determined that we're also going to want instance-store AMIs, as well as *encrypted* EBS AMIs. So, maybe there should be some discussion on that with the full group, since that will result in a large number of AMIs. If we end up building that many different combinations of storage types, volume types, and virtualization types, we're talking a fair amount of AMIs being kept up during the release process, because of how many image builds go through Koji. Dennis mentioned to me that there is some sort of Koji bug that, if fixed, would builds be marked as either "real life" or "scratch", so we could at least cut down a bit on the number of AMIs being built.

I think this discussion should continue a bit more based on all that. However, I *do* move that I immediately delete at least all the alpha, beta, TC, and RC builds that were created back when we were working on F21.

-- David