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.


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.