Monthly Archives: February 2014

Fedora Server Technical Specification Working Session (Day One)

Day One

Yesterday, the Fedora Server Working Group met to put together the Technical Specification, as required by FESCo and the Fedora Advisory Board as part of the Fedora.next initiative.

Supported Architectures

After some discussion, the working group agreed that Fedora Server will initially support the ix86, x86_64 and armv7hl architectures. In the future, once hardware becomes readily available, Fedora Server will support 64-bit ARM achitectures as well.

Partitioning and LVM

An hour-long discussion was held on the selection of the default, guided storage path. We determined that there were several points that need to be discussed with the Anaconda and user-experience teams:

  • How difficult is it to have separate guided paths for the separate projects?
  • Is it acceptable to reduce the guided path to a single choice for the Server Product?

It was agreed by the Server WG that we would prefer the option for a single guided storage path. We also agreed that this preferred option would be to use the XFS filesystem on LVM.

The reasoning for the XFS choice is that we are reusing research performed by Red Hat that showed that XFS was the best-performing filesystem for the majority of server loads. Additionally, we want to support LVM for a variety of reasons, including but not limited to easy expansion of logical volume size and the potential for snapshotting.

We discussed the possibility of using LVM thin-provisioning instead of classic LVM, but reached no consensus. Discussion of this point will continue as we go forward. For Fedora 21, it will be mostly an implementation detail.

Firewall

The selection of the default firewall-manipulation solution was fairly straightforward. A few questions were raised on the list about the reasoning for using a daemon instead of the traditional iptables rules. However, the advantages to firewalld are several:

  • It provides a relatively simple public API that can be consumed by projects such as OpenLMI to be able to manage the firewall rules separately.
  • The command-line tools for firewalld are much simpler to use for the common cases (simple port opening/closing).
  • It is expected that the firewalld interfaces will remain constant when the kernel changes from iptables to nftables.

Server Desktop

Much discussion was had over how to handle a graphical console for the Fedora Server. Some of the WG counseled deferring an official answer on this until Fedora 22. Others argue that we need to have at least some answer to this, since there exist third-party applications that cannot be installed without a console.

No consensus was reached on a selection of desktop environment. We instead decided that we would simply provide comps groups for each of the desktop environments currently available in Fedora and provide no direct guidance or support for any of them at this time.

Software Installation

Related to the previous discussion about desktops, we also agreed that we will not restrict the install media (particularly the network install or pointing Anaconda at additional repos) from being able to install any packages from the wider repositories. Fedora Server SIG does not commit to supporting anything outside of the standard install and Roles beyond the support already provided by the Fedora community.

Day Two

I put together a rough draft of the Technical Specification on the wiki. There are a large number of open questions, so we will be having a second meeting of the working group today (2014-02-28) at 1500 UTC to go through them.

Primary Goals for Fedora Server in Fedora 21

At today’s Server Working Group meeting, we affirmed the vote that’s been happening on the mailing list regarding the first two Server Roles that we plan to package for the Fedora Server.

Domain Controller

We unanimously selected a “Domain Controller” Role (powered by FreeIPA) as our primary, blocking deliverable for the first release of the Fedora Server. There are several reasons behind this decision. First of all, the FreeIPA project already possesses many of the qualities that we desire in a Server Role: it glues together all of the technologies that it needs to make work, it can be installed very easily and it serves a clear, high-level purpose.

In addition, the Domain Controller Role will serve as a fundamental piece of the architecture for interacting with the rest of the Fedora Server Roles and ecosystem. By setting up and enrolling servers in a domain, we will be able to take advantage of single-sign-on capabilities and other centrally-managed identity features in our other roles, including the ability to manage the set of administrators allowed to deploy roles on machines.

Database Server

We also unanimously agreed that the second Role we would develop would be a Database Server. This was chosen because, like the Domain Controller Role, most further roles will rely on the presence of a stable, usable database. The selection of *which* of the open-source databases to use was slightly more diverse, with seven members of the Working Group favoring PostgreSQL, one preferring MariaDB and one abstention. As a result, we will proceed with PostgreSQL as the initial provider of the Database Server Role, with an option in the future to develop and support other databases as well.

The Database Server is being classified as “highly desirable”, but it is not a strict blocker to the first release of Fedora Server (the way that the Domain Controller Role is). We will try as hard as possible to ship both Roles in the first release, but if we one has to be deferred, it will be the Database Server Role.