Change Proposals for Fedora 23

Stephen Gallagher sgallagh at redhat.com
Wed Jun 3 12:43:08 UTC 2015


In addition to the PRD refresh that we are all looking at (*ahem*), we
also need to figure out what are the major efforts we're going to
engage in during the Fedora 23 cycle. Alpha Freeze for Fedora 23 will
be on July 28th[1], and that means we need to have at least a prototype
of what we want in Fedora 23 ready by that point.

I'll list some of the things that have been discussed on the mailing
list and in meetings recently and we can work from there. (I'll also
include my recommendations inline).

==============================
== File-sharing server role ==
==============================
=== Benefits ===

 * Simple, easy-to-use mechanism for producing a file-sharing host
using the CIFS and/or NFS protocols.
 * Clear gap in our offering today.

=== Requirements ===
 * Development of an API to manage the configuration.
 * Creation of a server role definition to provide the services.
 * Graphical interface for manipulating it (likely Cockpit, unless
another web-based tool can be adapted without sacrificing usability).
 

=== Issues/Risks ===

 * Cockpit developers have indicated they cannot spare the resources to
implement the GUI this cycle.

=== Recommendations ===
Ask for volunteers to work on the management API for Fedora 23 and
postpone cockpit and rolekit work until Fedora 24.


============================================
== Cockpit GUI for Domain Controller Role ==
============================================
=== Benefits ===
 * Easier setup of initial domain controller.
 * Demonstration of our commitment to converging capabilities into
Cockpit

=== Requirements ===
 * UI Design of role creation (started; thanks Andreas Nilsson!)
 * Resources familiar with JavaScript and D-BUS (acquired: we have a
GSoC student working on this)

=== Issues/Risks ===
 * Work is being done by a student as part of Google Summer of Code.
Student projects always carry some risk. GSoC schedule is a good fit
with the Fedora 23 schedule (recommended pencils-down date is before
Fedora 23 Beta)

=== Recommendations ===
Let's definitely move ahead with this one. I'm sure our student (Turner
England) will be motivated and excited to see his work featured
prominently as a deliverable. I will also be personally involved as one
of his two mentors (the other being Peter Volpe of the Cockpit team).


================================
== Containerized Server Roles ==
================================
=== Benefits ===
 * Server roles offered by containers will be unaffected by underlying
OS upgrades.
 * Containers written under the Nulecule specification will be possible
to migrate to the Fedora Atomic Platform (and possibly also OpenShift
v3) later.

=== Requirements ===
 * At least one proof-of-concept role (I am proposing memcached for
this, as it's very simple).
 * Ideally convert the Database Server role to a container format. Must
handle upgrades (or backup/restore) from F22 DB Role.
 * Docker package must be built for at least all primary arches (and
ideally the secondary arches as well).

=== Issues/Risks ===
 * More difficult to determine when upgrades are necessary and to apply
them.
 * Docker Hub only supports x86_64, so we will have to either provide a
hub of our own or build docker images in rolekit from Dockerfiles.

=== Recommendations ===
I will be working on at least the PoC role (memcached) at the direction
of my management at Red Hat, so we should probably treat this as a
given and go ahead with filing at least one Change Proposal.

I recommend for simplicity (and not adding to rel-eng's workload) that
we build the images in rolekit from Dockerfiles based on the latest
available RPMs in the standard Fedora package collection.

I also recommend that we defer attempting to completely solve the
docker image upgrade problem to Fedora 24 (there's some work going on
in the Atomic space that may be more mature by that point). I think for
a first attempt, it will be acceptable to just build the ability to
perform upgrades on demand and instead implement the notification of
upgrades at a later date.


==========================
== FreeIPA Replica Role ==
==========================

=== Benefits ===
 * Ability to set up a resilient domain
 * Fewer manual steps after the initial domain creation

=== Requirements ===
 * Mechanism to promote a domain client to a replica
 * Resources: This needs the heavy involvement of a FreeIPA developer
(simo?)

=== Issues/Risks ===
 * May require plumbing changes that cannot be completed in time.

=== Recommendations ===

Feedback needed from FreeIPA team before I can make any
recommendations.



[1] https://fedoraproject.org/wiki/Releases/23/Schedule
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20150603/3a0806b0/attachment.sig>


More information about the server mailing list