The Fedora Cloud Working Group met on June 7 and 8 in Raleigh to work on deliverables for Fedora 25 and beyond. As it turns out, we had a really productive set of discussions and have some good ideas for the Cloud Working Group going forward.

Some of the discussions were around immediate action items, some were around ideas of where we’d like to go – and these will require additional discussion with the larger community. As a reminder, the working group tries to operate on a consensus model and with transparency as much as possible. This means major decisions are usually only taken after a discussion has been held on the cloud@lists.fedoraproject.org mailing list and have either gotten enough +1’s from members to pass, pass via lazy consensus, or get knocked down for one reason or another.

Here’s a quick sweep of major topics that came up over the two days!

Super Chill Documentation

The working group has started a repository in GitHub to track the various pieces of documentation that have popped up while the group has been doing work. We are taking a “super chill” approach to documentation by throwing in material in a raw form that can be tweaked as needed to make sense to others.

Former FPL Jared Smith has volunteered to help with turning the documentation into a usable form for a wider audience.

Automated Testing

Another major topic of the FAD was to refine our testing goals, requirements, and components. The Fedora Docker Layered Build images will be making their, limited, debut in Fedora 24 with a Cockpit image. In the Fedora 25 timeframe we want to be able to deliver a wider range of images, but need to be able to test a wide range of images that may not have many common features. For example, we want to be able to test Super Privileged Containers (SPCs) (that require root) and non-SPCs to ensure that they do not require root.

Atomic host tests are being enhanced and improved, and the group is working on tests to allow for automated tests of monthly basic Cloud images.

Ever image author will be able to write their own tests that will be run after build. There will be a minimal set of required tests that every image maintainer will need to supply, and the ability for them to deliver expansive sets of tests. Layered images will be tested with Taskotron, and the tests will live in dist-git. Autocloud will be doing the remainder of testing using [Tunir] (http://tunir.readthedocs.io/en/latest/).

Fedora Docker Registry

There will be a Fedora Docker registry in the Fedora 24 timeframe that is non-scalable. In Fedora 25 we would like to scale this out to incorporate the mirror network. At registry.fedoraproject.org you’ll be able to “docker pull” the Cockpit image that’s built in the layered build system, as well as the default Fedora image. This will require passing the entire registry URL, rather than a Docker short name. We may discuss making short names possible in a later Fedora release, but for now we want to preserve standard Docker behavior.

Our vision for the future

We will continue to produce the Fedora Atomic Host with few frills to run Docker container and kubernetes. However, we’re looking towards a proposal to build a Fedora with OpenShift Origin integrated, for both containerized application runtimes as well as PaaS capabilities. Part of the idea is to have this accepted as a Fedora Incubator project (which, itself, is still in development stage). We spent several hours working with upstream OpenShift developers on the scope and requirements, to ensure that it’s a mutually beneficial collaboration.

Fedora Docker Versions

We created a plan and roadmap for Docker versions in Fedora releases to minimize the impact of major churn from upstream Docker releases. We want to ensure Fedora users have the latest releases while still ensuring that a update does not break existing Dockerized applications during a Fedora release cycle.

One of our delivery vehicles for Fedora Atomic Host and cloud editions is Vagrant. We’re working on more remote provider plugins and members of the cloud working group packaged multiple vagrant plugins and have package reviews approved for Digital Ocean, which means people can fire up instances in Digital Ocean using a Vagrant file on their local machine.

The topic of tools that seem to be gaining popularity in the realm of container centric application development that the Fedora Cloud WG believes to be pervasive in the coming years and how Fedora Cloud WG could provide an useful environment to the developers using these tools was discussed. There are action items to investigate various tools such as Otto and Atomic Developer Bundle are on the list of technologies the Fedora Cloud WG will be exploring as avenues to provide solutions to users.

Fedora Cloud Base Monthly

Even though many of the next-generation technologies are focusing directly on Fedora Atomic Host and Container applicaiton runtimes, the Fedora Cloud Base image is still something that is near and dear to many of the Fedora users and contributors such that they can consume a traditional Fedora image that can be managed by rpm, dnf, and other long time standard tools. Approved in the past as a deliverable, we now have the ground work in place and will be moving into action a Monthly Release cycle for this Cloud image for IaaS Cloud providers.

Public Cloud Provider Outreach

The Fedora Cloud WG at the request of many users within the community are going to be investigating the requirements to establish working relationships with various public cloud providers such that they can be included into our testing, release workflows, and hopefully into the standard fedimg export upload process.

The Working Group has also come up with some ideas about improvements for the presentation of the images to users on the main getfedora.org landing page for Cloud such that there are two buttons, one for “Download” and one for “Launch Instance” in which the former is for users whom would like to download a Cloud centric image for their own on-premise Cloud and “Launch Instance” would be for launching an instance in a public cloud provider. We hope to work with the Fedora Web team on some of these ideas to bring this to fruition.

Hack Session

Members of the FAD broke out into small groups to work on various topics relating to what had been previously covered in the FAD.

FAD participants worked on: * Researching what all is needed for future Fedora Atomic Host + OpenShift Origin proof of concept work, creating various Docker Images that will be the building blocks, and beginning to hack on the openshift-ansible playbooks/roles that will deploy OpenShift Origin in containers on Fedora Atomic Host * Various Event reports for CommOps * creating test cases for the Fedora Cloud Base Image in order to expand test coverage and help with the upcoming monthly release plans * packaging the previously mentioned vagrant plugins * working on taskotron features for docker layered image testing

Event Report and Participants

Finally, we got together and did a debrief in order to write up this event report of the Fedora Cloud WG FAD 2016! The FAD, and this report, were a group effort – thanks to all the following who participated:

Matthew Miller, FPL

Adam Miller, Fedora Engineering

Josh Berkus, Project Atomic

Jared Smith, Fedora Community

Joe Brockmeier, OSAS

Clint Savage, Atomic OpenShift

Remy DeCausemaker, FCL

Scott Collier, Atomic End-to-End

Kushal Das, Fedora

Jason Brooks, OSAS

Colin Walters, Atomic (Remote)

Brian Exelbierd, Atomic Community (Remote)

(Apologies to anyone I missed!) And, of course, thanks to the Fedora Council for making the FAD possible. Special thanks to Josh Berkus for heading up the FAD!