Changes/(A)Periodic Updates to Cloud Images

(A)Periodic Updates to Images

Summary

We want to be able to release updated images not just at release time. Hope for a one-month regular cadence, plus emergency updates if needed.

Owner

• Name: Cloud WG collectively, Matthew Miller as point of contact.
• Email: cloud at lists.fedoraproject, mattdm at fedoraproject
• Release notes owner:
• Product: Cloud
• Responsible WG: Cloud

Current status

• Targeted release: Fedora 21
• Last updated: 2014-04-08
• Tracker bug: <will be assigned by the Wrangler>

Detailed Description

We need to be able to produce official updates to the Fedora Cloud images. Initially, we plan to release these updates monthly, but also need the ability to release an out-of-cycle update in the event of a severe security issue.

This involves:

1. policy for level of security issue required for out-of-cycle updates
2. procedure for notification of security updates in images (as with rpm updates)
3. automated QA (at least smoketests)
4. documentation of QA expectations
5. release engineering process
6. mirroring of updated images
7. updates to web site for new download links and EC2 AMI IDs.

Note that this will apply to the Cloud Base Image, the Docker Host Image, the Big Data Image, and the Docker Container Base Image. (The latter may need separate handling.)

Ultimately, we would like to produce updates whenever a package on the image or the kickstart file for the image changes. This is a step towards that goal.

Benefit to Fedora

When a massive security problem hits Fedora, we currently do image updates manually. Because this is exceptional, there is a lot to go wrong, and of course, things always go wrong at the worst possible times. The primary benefit of this change is to make image updates routine, so that when emergency update happens, we can handle it as if it were no big deal.

The actual updated images are, of course, a valuable secondary benefit. Since cloud images are usually short-lived, this allows new instances to be created without the overhead of applying several months' updates.

Scope

• Proposal owners: Create policies and procedures as outlined above. Will also assist with changes to release engineering.

• Other developers: Contributions welcome!

• Release engineering: Significant impact, obviously. Cloud WG will interact heavily with Release Engineering and work in concert.

• Policies and guidelines: No changes to existing policies.

Upgrade/compatibility impact

Users are expected to replace one image with the next.

How To Test

The test of this feature is simply whether new images are available and functional.

Tests of the image are part of the feature proposal itself.

User Experience

Users will be able to select versioned images for download or launch in cloud providers. We may provide a simple web service for selecting images, (perhaps compatible with simplestreams).

Dependencies

No package dependencies but there are significant dependencies on release engineering.

Contingency Plan

• Contingency mechanism: continue to do updates by hand
• Contingency deadline: technically, first critical security update after F21 release, or first month after, whichever comes first.
• Blocks release? no
• Blocks product? no

Documentation

TBD

Release Notes

Let's not make promises in the release notes.