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@xxxxxxxxxxxxxxxxx> _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
