>
> 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
--
security mailing list
security@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/security
