[cloud] #51: start communication/collaboration on cloud image updates

[Fedora Cloud Trac Tickets]

#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