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