Speaking as the SRT guy responsible for the RHT end of this fire drill
this is something we want to avoid in future, and some things are
already in progress, once I make some progress I was planning to talk
to the Fedora (and possibly others).
That fire drill will likely happen again at some point. It needs to be
planned for.
One problem with AWS for example is even if you respin the image it
has a new AMI (Amazon Machine Instance) ID, so any systems launching
Fedora servers automatically will include that old AMI ID until it is
manually updated. Only people going through the Marketplace or
searching for "Fedora" will get the latest one.
I think there are two different problems here.
There is the issue of doing a respin of images (this includes what you
download off a mirror). Then there is the issue of updating existing
images. Neither problem is simple.
I had thought about a stub RPM like "cloud-update" that could contain
cloud specific updates/etc, some problems crop up like do we do one
per service provider (since we can't reliably detect which provider
we're on without doing some potentially dangerous things), who
maintains it, how do we handle situations where we push out an
emergency update through the cloud-update thing and then push an
actual updated cloud image, we need to ensure the image and the
cloud-update don't conflict to name a few of the simpler problems.
I still don't really like this solution. The right thing to do is to break
the problems apart into manageable bits.
I'd think the first problem is just understanding how should an image
respin work? Some questions to answer:
* What sort of event could cause a respin?
* Who is responsible for the respin event?
* How do we communicate a respin event?
* What do we do with the old images?
I'm sure there are plenty more questions, those are the ones that come to
mind.
Thanks.
--
JB