Future directions for Fedora Cloud

[Matthew Miller]

By now, many of us will have seen the "Three Products" strategy for Fedora
as discussed at Flock and approved by the board last week. (If not, see
<https://fedoraproject.org/wiki/Fedora.next/boardproposal>).

Although the initial Cloud SIG focus was on producing a great guest image,
generally we've got participants interested in all things cloud, from
private cloud IAAS software running on metal all the way to the top of the
stack. I don't think that will (or should) change -- it's good to have a
broad group interested in the whole picture.

The new Fedora Cloud Working Group (which I hope to see many of you signing
up for -- there will be a call-for-participation message coming soon) will
be a subset working specifically on Fedora as a cloud guest OS. What that
exactly _means_ will be up to the working group to determine.

The split from Fedora Server gives us some interesting room for exploration.
It _could_ simply be that the cloud image is the Fedora Server OS, but
tailored to run in a virtual environment and with cloud-init. That's roughly
what we do now, really. But, if we want to, we can draw the division very
differently.

I've been thinking of two other possible approaches for this and I'd like to
hear your thoughts (and, again, get your involvement in the working group).
Both of these ideas might include the idea of having the Fedora Server
product actually also produce AMIs and qcow2 images as we do now from this
SIG. That would cover the use cases which are basically "I want a
traditional Fedora system, but I want it in the cloud". For that reason,
we'd probably want a different marketing name than Fedora Cloud.
(Suggestions eventually welcome, but let's talk about the bigger ideas
first.)

So, idea one is to make something like CoreOS (http://coreos.com/): a
lightweight distribution made for running containers on top of. We wouldn't
attempt to be _as_ lightweight as CoreOS (for that, there's CoreOS), but aim
to be small while still providing key features like SELinux. Perhaps this
could be built with Colin Walter's OSTree (see
https://wiki.gnome.org/OSTree) for atomic updates. Then, we would provide
something like Docker or an OpenShift interface for launching and running
the actual code on top of that.

Idea two is to focus instead on what goes _in_ those containers. As far as I
can see, this is a largely open space and not very well addressed overall,
let alone within Fedora. We could focus on 1) a process for building
container images out of Fedora through release engineering (tracking source
code all the way to the end result, helping with license compliance issues
and verifiability) and 2) an easy way to remix these images plus a
marketplace for those remixes. 

With idea two, we could either _also_ do idea one (or idea zero, continuing
on the current path), or we could simply ask the Fedora Server product to
please provide the underlying layer.

Does this sound interesting / valuable? Are there other directions you'd
like to see us go?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm at fedoraproject.org>