#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-
wavy)
* 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
process:
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
clouds
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
immediately deregistered/deleted
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
https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/what_to_test ...
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
update.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/51#comment:6>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
