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(a)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.