Cloud image lifetimes

[Ryan Brown]

On 03/24/2015 01:51 PM, David Gay wrote:
> 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

+1 for instance-store AMIs, they're incredibly useful. I think it's a
good time to think about what AMIs we should be producing though, and
talk to FESCO about just how much we're willing to spend on providing AMIs.

> 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.

+1 sounds like a good plan for now.

> 
> -- David _______________________________________________ cloud
> mailing list cloud at lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of
> Conduct: http://fedoraproject.org/code-of-conduct
> 

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