Cloud Changelist

From FedoraProject

These are the changes the Fedora Cloud Working Group proposes for Fedora 21. We have organized this list into external dependencies, which represent changes primarily in areas other than the Cloud SIG, and Changes, which we will file using the normal Fedora process. We believe all of the change proposals are self-contained. The external dependencies may also be filed as system-wide changes. Each of these will have at least one Cloud SIG member
as a contributor to the effort.

External Dependencies

Some of the things the Fedora Cloud Working Group would like to see require changes that are largely in the areas of other Fedora groups. The enhanced automatic QA features of Taskotron are be an example; web design and marketing are others. For each of these, we will find someone from the Cloud SIG to take responsibility, including contributing effort where applicable.

External Need: Automatic Image Upload

Summary: Whenever an image is built, it is automatically uploaded to our cloud provider targets (EC2, etc.) and to the fedora ftp site (and possibly mirrors if we can convince mirror admins to drink from that firehose)

Importance: vital (current process where rel eng does it by hand will not scale)

Timeframe: whenever we can get it / this adds value whenever it happens

External Need: Updated Web Site

Summary: Since we are now one of the three top level artifacts Fedora produces, we want to emphasize our unique niche. Updated website with new flashier branding, plus tools for selecting different images for different use cases

Importance: vital (it's basically part of the whole exercise)

Timeframe: F21 release / arguably, having the web site up _is_ the release. And it'd be nice to have earlier, like at the alpha and beta

Change Proposals

These are not all yet filed; this list is effectively a statement of intent-to-create, in order to collect feedback and better work together with the other groups involved in each.

Change: Move to ImageFactory For image Creation

Summary: Create images using Anaconda in Koji rather than appliance-creator. Allows fedmsg integration for upload service, and also could produce official Docker images.

Importance: vital (basic image creation is nice-to-have, fedmsg integration is important to automation, and producing Docker images is strategically vital)

Timeframe: at least a month lead time before F21 alpha / If we are going to release images made this way, we need them made that way for early testing, and there will be some porting work to the kickstart

Change: Install without i10n / l18n support (w/optional install)

Summary. We need to have a cloud image without the overhead/extra space requirements of i10n / l18n support, but want to provide the option to install these packages if needed. In many cases these are not necessary for images running in the cloud.

Importance. moderate (Should not be overly difficult to implement, but is not a show-stopper if it's not complete by F21.)

Timeframe. F21 alpha / should be at least mostly implemented by alpha or won't be ready for this release.

Change: Install without documentation (w/optional install later)

Summary. In many cases, users will not want documentation on cloud images. We should be able to provide support to create/deliver cloud images without documentation but still have it available for installation if desired.

Importance. moderate

Timeframe. F21 alpha / should be at least mostly implemented by alpha or will not be ready for this release.

Change: Refactor cloud-init

Summary. Cloud Init was initially designed for a different distribution and is only loosely tailored for our needs. As it stands, it pulls in a rather large set of packages not used for other things. It is also written in Python, itself a large subsystem which it would eventually be nice to leave out of the base. Effort is moderate, with some low-hanging fruit which may be addressed easily.

Importance. vital long term, but just moderate for F21 (We really need this, but if we don't get work it now, it's in acceptable shape for this release.)

Timeframe. F21 alpha, or F22 / if we don't make alpha with changes, this can go in next release.

Change: Modularized SELinux Packaging'

Summary: Monolith SELinux policy has rules for everything that could exist, not just that which is installed. Possible room for reduction here.

Importance: nice-to-have

Timeframe: F21 or F22 / This is not low-hanging fruit.

Scope: self-contained (SELinux)

Cloud SIG owner: TBD

(No Feature filed at this time -- discuss with SELinux policy maintainers)

Post-Fedora 21 Plans

Image or Image Template Library

Summary. In addition to the basic tooling for image creation, we want to enable sharing of user-created images and their recipies. This may apply to Docker or other container images in addition to images targetted at full virtualization.

Importance. vital (Post-Fedora 21 when the rest of the tooling/work settles, it will be crucial to offer users ready-made templates and help create a larger community around building images for Fedora.)

Timeframe. This should be targeted post-Fedora 21 and be ready by F22 or before. Depends on work landing in F21, so delivery before that is unlikely.

Scope. Depends on several features targeted for F21.

Dropping 32-bit x86, adding ARM

Summary. Initially, we will target 32 and 64-bit x86. As ARM-based cloud systems become available, we will add ARM images. We may consider dropping 32-bit x86 in the future.

Importance. vital (We want to be a leader in ARM. And, dropping 32-bit x86 will free up resources.)

Timeframe. Post-F21 for ARM, because ARM is not yet widespread (even among early adopters and innovators) in public or private clouds. We may consider dropping 32-bit x86 for F21 if other products are doing so as well.