At today's FESCo meeting, FESCo approved https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Cloud_Images but wants us to get started actually changing the hand-waving parts about
We really need people to sign up for each of these -- not necessarily to do all the work, but to take ownership of the communication and coordination for each.
See also: https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs
See also:
Status update for this week is that things are basically moving forward but it isn't ready yet for doing "cloudy things". Taskotron is reaching a useful stage.
Leaving this ticket open for a status update next week.
agrimm will look at this.
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.
Will document this (requesting a new image from releng) on a Wiki page after I make sure I know what I'm doing... Please poke me next meeting if this doesn't happen by then.
From the #fedora-cloud meeting today: roshi, all: it is believed this ticket can be closed. Is there any work left to do?
Since this hasn't had any traffic in 10 days I'm going to go ahead and close it out.
Login to comment on this ticket.