Cloud Changelist

Brainstorming

Remove this section as ideas are put into a more structured form (or discarded).

• Retire appliance-creator
  • Anaconda-based installs are the way forward
    • Needs new ImageFactory release
    • Patch Koji for ImageFactory support
    • Then, needs new Koji release
    • Then, push new Koji release to Fedora production
• Extend AutoQA to allow for automated testing of cloud images (if not already possible)
• Automate rel-eng
  • produce scratch builds on change (note: we already have nightly images of rawhide and branched compose for months)
  • upload final release and re-release images to ec2 and ftp
• Updated Web Site for Obtaining Cloud Images
  • Easier access to provided images for various use cases
  • Provide build toolchain
  • encourage community to use toolchain to build new products
  • Allow folks to share and review the work done by their peers
• Implement new procedures for (a)periodical re-releases
• Ensure usability of software stacks for cloud usage
  • Always have several different versions (major or minor releases, i.e. non-bugfix releases) ready for installation
  • Make sure older versions are supported and available as long as possible, particularly with new Fedora releases
    • i.e. apps running on F21 cloud images should still be able to run on F22 cloud images (and F23? How long should they work?)
• More modularly-packaged kernel (modules that are not necessary in virtualized environments need become optionally installable)
• More modularly-packaged (or written?) SELinux policies
• Make it possible to install without l10n/i18n support (no extra languages, etc.) but keep the possibility to install them
• Make it possible to install packages without documentation (to save space) but keep the possibility to install them

Suggested Structure

Basically, each of these are going to become a Change using the Fedora Features process (Changes/Policy). So, each should be a very lightweight version of Changes/EmptyTemplate. We should also rate each one for importance (overall/strategically) and urgency (things that need to get done *now*, things that need to land in f21, things that can land after) + a rationale for the urgency (blocks something, competitive need, etc).

So, I'm envisioning a list here which looks like this:

Change Name

Summary: Elevator pitch for the change. Importance: [ vital | moderate | nice-to-have ] Timeframe: [ now | F21 alpha | F21 beta | F21 release | F22 | F23+ ] / reason (e.g. "blocks ability to produce images" ) Scope: [ self-contained | complex system-wide ] link to change proposal page (can be not actually filled out yet)