From Fedora Project Wiki

(Brainstorming based on Cloud ToDo and Cloud PRD)
 
 
(30 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Brainstorming ==
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
Remove this section as ideas are put into a more structured form (or discarded).
as a contributor to the effort.
* Retire appliance-creator
 
** Anaconda-based installs are the way forward
 
*** Needs new ImageFactory release
== External Dependencies ==
*** Patch Koji for ImageFactory support
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.
*** 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)
=== External Need: Automatic Image Upload ===
* Automate rel-eng
 
** produce scratch builds on change (or at least nightly builds?)
'''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)
** upload final release and re-release images to ec2 and ftp
 
* Updated Web Site for Obtaining Cloud Images
'''Importance:'''  vital (current process where rel eng does it by hand will not scale)
** Easier access to provided images for various use cases
 
** Provide build toolchain
'''Timeframe:''' whenever we can get it / this adds value whenever it happens
** encourage community to use toolchain to build new products
 
** Allow folks to share and review the work done by their peers
'''Fedora Sub-Project/SIG:''' Release Engineering, possibly Infrastructure for resources
* Implement new procedures for (a)periodical re-releases
 
* Ensure usability of software stacks for cloud usage
'''Cloud SIG owner:''' TBD (note summer intern may help with that, if it is not too late)
** 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
Possibly we file this as a change. Also see previous intern's initial work: https://git.fedorahosted.org/cgit/cloud-image-service.git/
*** 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
=== External Need: Updated Web Site===
* Make it possible to install packages without documentation (to save space) but keep the possibility to install them
 
'''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
 
'''Fedora Sub-Project/SIG:''' Websites
 
'''Cloud SIG owner:'''  Joe Brockmeier
 
https://fedorahosted.org/fedora-websites/ticket/248
 
----
 
=== External Need: Software Collections for Cloud Users ===
 
'''Summary:''' Provides selection of language stacks of particular versions to users.
 
'''Importance:''' vital (provides a meaningful reason to use Fedora cloud image, and helps insulate against rapid change)
 
'''Timeframe:''' F21 release / This is a requirement of users in production.
 
'''Fedora Sub-Project/SIG:''' Environments and Stacks
 
'''Cloud  SIG owner:''' TBD
 
Draft feature proposal: https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/SCL
 
----
 
=== External Need: Batched Updates ===
 
'''Summary:'''  We want to produce updated images on a monthly cadence. It would be  nice if we could produce those from QA'd bunches of packages.
 
'''Importance:''' moderate (it will be hard to implement image refresh without this, but we could do it)
 
'''Timeframe:''' F21 release + 1 month / Obviously better if we get things lined up earlier
 
'''Fedora Sub-Project/SIG:''' Primarily QA, but Rel Eng and Infrastructure too. This is pretty big.
 
'''Cloud  SIG owner:''' TBD (this probably needs someone actively  contributing to initial and ongoing work)
 
See the related Change  proposal "(A)Periodic Updates to the Images"
 
http://flock2013.sched.org/event/8c4f702e42814598e0e4e31b188a0ae6
 
----
 
=== External Need: Automatic Smoketests on Image Build ===
 
'''Summary:''' When a new image is built in Koji, automatically boot it and run a basic matrix of tests.
 
'''Importance:''' moderate (worst case, we can keep doing this by hand)
 
'''Timeframe:''' F21 alpha / Want to reduce manual test workload
 
'''Fedora Sub-Project/SIG:''' QA and the Taskotran project
 
'''Cloud SIG owner:''' [[User:red|Sandro Mathys]]
 
https://fedoraproject.org/wiki/Taskotron
 
----
 
=== External Need: Scratch Builds on Change ===
 
'''Summary:'''  Whenever the kickstart changes, _or_ an RPM which is on the image hits  the tree, a new scratch image is automatically built.
 
'''Importance:''' nice to have (makes development much easier, and makes it quick to spot  and fix problems before they affect anyone)
 
'''Timeframe:''' whenever we can get it / this adds value whenever it happens
 
'''Fedora Sub-Project/SIG:''' Release Engineering, possibly Infrastructure for resources
 
'''Cloud SIG owner:''' TBD
 
(need link to something further -- possibly we file this as a change)
 
----
 
== 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 non-scratch builds with 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
 
'''Scope:''' self-contained (work with Rel Eng)
https://fedoraproject.org/wiki/Changes/ImageFactory_in_Koji
 
'''Cloud  SIG owner:''' mattdm
----
 
=== Change: (A)Periodic Updates to the 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.
 
'''Importance:'''    vital (People don't like to yum update their images, and since we  change so much, doing so is a significant launch delay. let's make it  so they don't have to, but still get updates)
 
'''Timeframe:''' F21 final + 1 month / Obviously better if we get things lined up earlier
 
'''Scope:''' self-contained (but depends on bigger changes across the project)
https://fedoraproject.org/wiki/Changes/(A)Periodic_Updates_to_Images
 
'''Cloud  SIG owner:''' TBD
 
----
 
=== Change: Docker Host Image ===
 
'''Summary:'''  Fedora Cloud agreed to  make a base image plus several tailored to  specific purposes. This is one of the tailored ones — Docker host ready  to go.
 
'''Importance:'''  moderate (Docker is hot stuff and we need an answer to CoreOS, but if  we fail to do it, we are not any worse-off than we are now, and Docker  can still be used on the base iamge.)
 
'''Timeframe:''' F21 alpha / If it's not ready for alpha, we have missed this release
 
'''Scope:''' system-wide
https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image
 
'''Cloud  SIG owner:''' [[User:red|Sandro Mathys]]
 
'''N.B.''' We may consider [http://rpm-ostree.cloud.fedoraproject.org/ Fedora Atomic Initiative] for this image, depending on degree of effort on that project across the rest of Fedora.
 
----
 
=== Change: Adopt-Your-Cattle ===
 
'''Summary:''' We want to provide a smooth path so a Cloud base image can be turned into Fedora Server
 
'''Importance:'''  moderate (Fits the lines we've drawn between the products while still  giving people a simple path to running Fedora as a traditional server  in  a public or private cloud)
 
'''Timeframe:'''  F21 beta / This needs testing.
 
'''Scope:''' self-contained (in collaboration with Server WG)
 
'''Cloud  SIG owner:''' TBD
 
https://fedoraproject.org/wiki/Changes/Adopt-Your-Cattle
 
=== 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.
 
'''Scope.''' self-contained
 
'''Cloud SIG owner.''' mattdm (I already have a conversation open with anaconda and the packaging team)
https://fedoraproject.org/wiki/Changes/Optional_i10n_and_l18n_support_cloud_image
 
----
 
=== 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.
 
''' Scope.''' self-contained
 
'''Cloud SIG owner.''' mattdm
 
https://fedoraproject.org/wiki/Changes/Optional_documentation_cloud_image
 
----
 
=== 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.
 
'''Scope.''' Self-contained
 
'''Cloud SIG owner.''' TBD
 
https://fedoraproject.org/wiki/Changes/Refactor-cloud-init
 
----
 
=== Change: Big Data Image ===
 
'''Summary:'''  Fedora Cloud agreed to  make a base image plus several tailored to  specific purposes. This is one of the tailored ones, produced in  collaboration with the Big Data SIG.
 
'''Importance:'''  nice to have (if we fail to do it, we are not any worse-off than we are  now, and big data tools can still be used on the base iamge.)
 
'''Timeframe:''' F21 alpha / If it's not ready for alpha, we have missed this release
 
'''Scope:''' self-contained (in collaboration with Big Data SIG)
 
'''Cloud  SIG owner:''' TBD
 
https://fedoraproject.org/wiki/Changes/Big_Data_Cloud_Image
 
----
 
=== Change: OpenShift Out-of-the-Box Image ===
 
'''Summary:'''    Fedora Cloud agreed to  make a base image plus several tailored to    specific purposes. This is one of the tailored ones — OpenShift ready to run.
 
'''Importance:'''    nice to have (if we fail to do it, we are not any worse-off than we are  now, and OpenShift can still be installed on the base iamge.)
 
'''Timeframe:''' F21 alpha / If it's not ready for alpha, we have missed this release
 
'''Scope:''' self-contained (in collaboration with OpenShift developers)
 
'''Cloud  SIG owner:''' TBD
 
https://fedoraproject.org/wiki/Changes/OpenShift_Out-of-the-Box_Cloud_Image
 
----
 
=== Change: Docker Container Image ===
 
'''Summary:'''  This is Fedora running inside Docker. Currently, there are non-official  images in the docker index, but we'd like them to really come out of  release engineering.
 
'''Importance:'''  nice to have (The unofficial image situation is not ideal. Plus, this  is an area where we can show leadership.)
 
'''Timeframe:''' F21 alpha / If it's not ready for alpha, we have missed this release
 
'''Scope:''' self-contained
 
'''Cloud  SIG owner:''' TBD (mattdm to kick things off)
 
https://fedoraproject.org/wiki/Changes/Docker_Container_Image
 
----
 
=== Change: Cloud-Friendly Kernel Packaging ===
 
'''Summary:''' Modules that are not necessary in virtualized environments become optionally installable
 
'''Importance:''' nice-to-have
 
'''Timeframe:''' F21 beta / need widespread testing to make sure nothing really needed is left out
 
'''Scope:''' self-contained (kernel team with input/feedback from cloud)
 
'''Cloud  SIG owner:''' [[User:red|Sandro Mathys]]
 
https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud
 
----
 
=== 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.
 
'''Scope.''' self-contained
 
----

Latest revision as of 15:06, 3 April 2014

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

Fedora Sub-Project/SIG: Release Engineering, possibly Infrastructure for resources

Cloud SIG owner: TBD (note summer intern may help with that, if it is not too late)

Possibly we file this as a change. Also see previous intern's initial work: https://git.fedorahosted.org/cgit/cloud-image-service.git/


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

Fedora Sub-Project/SIG: Websites

Cloud SIG owner: Joe Brockmeier

https://fedorahosted.org/fedora-websites/ticket/248


External Need: Software Collections for Cloud Users

Summary: Provides selection of language stacks of particular versions to users.

Importance: vital (provides a meaningful reason to use Fedora cloud image, and helps insulate against rapid change)

Timeframe: F21 release / This is a requirement of users in production.

Fedora Sub-Project/SIG: Environments and Stacks

Cloud SIG owner: TBD

Draft feature proposal: https://fedoraproject.org/wiki/Env_and_Stacks/Changes_Drafts/SCL


External Need: Batched Updates

Summary: We want to produce updated images on a monthly cadence. It would be nice if we could produce those from QA'd bunches of packages.

Importance: moderate (it will be hard to implement image refresh without this, but we could do it)

Timeframe: F21 release + 1 month / Obviously better if we get things lined up earlier

Fedora Sub-Project/SIG: Primarily QA, but Rel Eng and Infrastructure too. This is pretty big.

Cloud SIG owner: TBD (this probably needs someone actively contributing to initial and ongoing work)

See the related Change proposal "(A)Periodic Updates to the Images"

http://flock2013.sched.org/event/8c4f702e42814598e0e4e31b188a0ae6


External Need: Automatic Smoketests on Image Build

Summary: When a new image is built in Koji, automatically boot it and run a basic matrix of tests.

Importance: moderate (worst case, we can keep doing this by hand)

Timeframe: F21 alpha / Want to reduce manual test workload

Fedora Sub-Project/SIG: QA and the Taskotran project

Cloud SIG owner: Sandro Mathys

https://fedoraproject.org/wiki/Taskotron


External Need: Scratch Builds on Change

Summary: Whenever the kickstart changes, _or_ an RPM which is on the image hits the tree, a new scratch image is automatically built.

Importance: nice to have (makes development much easier, and makes it quick to spot and fix problems before they affect anyone)

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

Fedora Sub-Project/SIG: Release Engineering, possibly Infrastructure for resources

Cloud SIG owner: TBD

(need link to something further -- possibly we file this as a change)


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 non-scratch builds with 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

Scope: self-contained (work with Rel Eng) https://fedoraproject.org/wiki/Changes/ImageFactory_in_Koji

Cloud SIG owner: mattdm


Change: (A)Periodic Updates to the 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.

Importance: vital (People don't like to yum update their images, and since we change so much, doing so is a significant launch delay. let's make it so they don't have to, but still get updates)

Timeframe: F21 final + 1 month / Obviously better if we get things lined up earlier

Scope: self-contained (but depends on bigger changes across the project) https://fedoraproject.org/wiki/Changes/(A)Periodic_Updates_to_Images

Cloud SIG owner: TBD


Change: Docker Host Image

Summary: Fedora Cloud agreed to make a base image plus several tailored to specific purposes. This is one of the tailored ones — Docker host ready to go.

Importance: moderate (Docker is hot stuff and we need an answer to CoreOS, but if we fail to do it, we are not any worse-off than we are now, and Docker can still be used on the base iamge.)

Timeframe: F21 alpha / If it's not ready for alpha, we have missed this release

Scope: system-wide https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image

Cloud SIG owner: Sandro Mathys

N.B. We may consider Fedora Atomic Initiative for this image, depending on degree of effort on that project across the rest of Fedora.


Change: Adopt-Your-Cattle

Summary: We want to provide a smooth path so a Cloud base image can be turned into Fedora Server

Importance: moderate (Fits the lines we've drawn between the products while still giving people a simple path to running Fedora as a traditional server in a public or private cloud)

Timeframe: F21 beta / This needs testing.

Scope: self-contained (in collaboration with Server WG)

Cloud SIG owner: TBD

https://fedoraproject.org/wiki/Changes/Adopt-Your-Cattle

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.

Scope. self-contained

Cloud SIG owner. mattdm (I already have a conversation open with anaconda and the packaging team) https://fedoraproject.org/wiki/Changes/Optional_i10n_and_l18n_support_cloud_image


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.

Scope. self-contained

Cloud SIG owner. mattdm

https://fedoraproject.org/wiki/Changes/Optional_documentation_cloud_image


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.

Scope. Self-contained

Cloud SIG owner. TBD

https://fedoraproject.org/wiki/Changes/Refactor-cloud-init


Change: Big Data Image

Summary: Fedora Cloud agreed to make a base image plus several tailored to specific purposes. This is one of the tailored ones, produced in collaboration with the Big Data SIG.

Importance: nice to have (if we fail to do it, we are not any worse-off than we are now, and big data tools can still be used on the base iamge.)

Timeframe: F21 alpha / If it's not ready for alpha, we have missed this release

Scope: self-contained (in collaboration with Big Data SIG)

Cloud SIG owner: TBD

https://fedoraproject.org/wiki/Changes/Big_Data_Cloud_Image


Change: OpenShift Out-of-the-Box Image

Summary: Fedora Cloud agreed to make a base image plus several tailored to specific purposes. This is one of the tailored ones — OpenShift ready to run.

Importance: nice to have (if we fail to do it, we are not any worse-off than we are now, and OpenShift can still be installed on the base iamge.)

Timeframe: F21 alpha / If it's not ready for alpha, we have missed this release

Scope: self-contained (in collaboration with OpenShift developers)

Cloud SIG owner: TBD

https://fedoraproject.org/wiki/Changes/OpenShift_Out-of-the-Box_Cloud_Image


Change: Docker Container Image

Summary: This is Fedora running inside Docker. Currently, there are non-official images in the docker index, but we'd like them to really come out of release engineering.

Importance: nice to have (The unofficial image situation is not ideal. Plus, this is an area where we can show leadership.)

Timeframe: F21 alpha / If it's not ready for alpha, we have missed this release

Scope: self-contained

Cloud SIG owner: TBD (mattdm to kick things off)

https://fedoraproject.org/wiki/Changes/Docker_Container_Image


Change: Cloud-Friendly Kernel Packaging

Summary: Modules that are not necessary in virtualized environments become optionally installable

Importance: nice-to-have

Timeframe: F21 beta / need widespread testing to make sure nothing really needed is left out

Scope: self-contained (kernel team with input/feedback from cloud)

Cloud SIG owner: Sandro Mathys

https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud


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.

Scope. self-contained