#51: start communication/collaboration on cloud image updates
Reporter: mattdm | Owner: roshi
Type: task | Status: assigned
Priority: normal | Milestone: Future
Component: --- | Resolution:
Keywords: meeting |
Comment (by arg):
I talked to roshi about this today. Neither of us has great familiarity
with the processes and who owns what up to this point, so we're probably
going to be stating the obvious for some of this, and entirely incorrect
for other parts. Feel free to correct us.
Generally, the decision that an updated image needs to be
built/tested/published will rest with the Cloud WG (though others are
certainly free to politely suggest that an updated image be produced).
Criteria which may trigger this:
* An important security update (in which case the security team might
require that a new image be built)
* A major bugfix to cloud-init, systemd, or another package which
addresses a boot-time problem that would impede bringing up the system far
enough to apply updates
* A number of available updates such that running a simple "yum update"
would be undesirably costly / time-consuming (yes, this is still hand-
* Support for a new cloud feature / metadata format / etc.
I'm not sure if there's any case other than security where the decision to
produce a new image rests outside of the Cloud WG. Thoughts on this?
As for the process, I'm still learning here. I _think_ this is the
1) Once the decision is made to produce an image, releng will trigger it
(based on a specific compose?)
2) If the image succeeds, fedimg will see a message and trigger uploads to
2a) talked to oddshocks -- he's okay with making the image private
during testing, but the code does not do this yet.
3) fedimg has hooks for running tests, and if the tests fail, the image is
4) if the tests pass, fedimg should make the image public, then emit a
fedmsg that the new image is available.
As for _what_ to test, this is covered by
it's a short list, but this is desirable. We may add to it, but should
keep in mind that the primary purpose of the base image is to boot, allow
a user to login, and allow provisioning / config management tools to
modify it. If all of that works, anything else can fix fix with a yum
Ticket URL: <https://fedorahosted.org/cloud/ticket/51#comment:6>
Fedora Cloud Working Group Ticketing System