This is the continuation of part four of a series based on talks at February at DevConf in the Czech Republic. I was going to cover all of the reports from each of the Working Group liaisons in one post, but that turned out to be quite a wall of text, so I’m going to do them one by one, with Stephen Gallagher from the Fedora Server Working Group this week.
You should start with Part I, ”Why?”, and if you enjoy the general concepts of “logical progression” and “putting the horse before the cart”, I suggest following that with Part II, “What’s Happening?” and then Part III, “Governance, Progress, and More Ideas”.
If you missed the previous Working Group reports, they’re at Part IV, a and b, Base Design and Environments and Stacks.
You can watch the video on YouTube, but you may find the text more helpful. I’ve summarized and paraphrased instead of just transcribing. And, since it has been three months, I’ve gotten updates from each speaker.
Working Group Report Video
Fedora Server: Stephen Gallagher
Stephen says that the Fedora Server Working Group is intended to be the place for development of “the next stable platform for Linux”. He explains that this doesn’t just mean downstream RHEL or CentOS, but that upstream projects should look at us and see a place to work for integration of technologies that might be in all of the various stable platforms in three years.
One of the first things the working group discussed was how Fedora Server and Fedora Cloud would fit together, and Stephen presents the “pets vs. cattle” metaphor. “Pets” represent the more traditional infrastructure approach, where you have a server, and when it gets sick, you take it to the vet, you care for it, and you do everything you can to sustain its life. On the other hand, the new “cattle” model in the DevOps world: if you have a cow that’s not behaving itself, shoot it in the head and buy another cow.
The goal of the the Server Working Group is to address the “pets” side of the environment. Fedora Server will handle the critical infrastructure systems which are more traditional, or which even going into the future we don’t expect to adopt the “cattle” model. For example, you’re probably not going to have your domain controller operating in that way.
In order to address this, the Server Working Group will be building a new concept called “Server Roles”. This is going to be a type of (at this moment, a little bit handwavey) packaging that will allow us to deploy not just the set of packages that you would need to set up an infrastructure service, but also an automated and API-driven way to configure that. Ideally, this will provide as many best-practice defaults as possible, and present the user only a small set of answers that must be given.
So, the goal is to work with projects like OpenLMI and Cockpit so that we can have these deployable Server Roles. Admins will be able to just point at a machine and say “you’re now a domain controller!”, or “you’re a MySQL database!”.
In the months since the talk, the Server Working Group has settled on two initial Server Roles to distribute: Domain Controller (based on FreeIPA) and Database Server (based on PostgreSQL), and is building a D-BUS API and command-line tools to deploy and monitor these Server Roles, using Cockpit and OpenLMI for a GUI and scripting interface, as mentioned.
Visit the Server Working Group page on the Fedora Project wiki for further information, including the mailing list and IRC meeting times.
Watch for more of Part IV Next Week
Coming up, the summaries from the Workstation and Cloud product working groups. Since these are shorter than the earlier parts of this series, I’m going to try to do them at a slightly faster pace than only one a week; we’ll see how that goes. In any case, once the summary presentations are done, it’s on to Q&A.
As before, let’s continue this conversation in comments and replies, and in addition to responding, I’ll distill that into a final Q&A post at the end of this series (separate from the summary of the questions at the conference).
I think its time to discuss technicalities and not metaphors.
This post seems to be a more approachable overview of the plans. It also clearly states where to get more detailed (and technical) information:
This talk — and these posts! — is meant to give a background and a high-level view. A lot of people were asking for an understanding of the reasons we want to do this, and an overview of what it’ll mean. But that doesn’t mean that we don’t also have specifics. Have you seen, for example, the Fedora Server Technical Specification? And please feel free to join the mailing lists or the IRC channel as noted in the article and ask further about anything you’d like clarified.