Discussion of Fedora Server use-cases

[Miloslav Trmač]

On Mon, Oct 28, 2013 at 1:55 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
> I am also not committing us to covering any or all of these
> targets.

The question of how much energy can we devote and/or direct towards
any of the goals is, in a sense, critical to setting the right
ambitions.  But we'll not know until we try...

>  * Come up with standardized mechanisms for centralized monitoring
>  * Come up with standardized mechanisms for centralized configuration
> and management

I think these two are really important.  I'd like the Server to be as
close to zero "bullshit maintenance" as possible, automating
everything that is automatable.  E.g.
* The administrator doesn't have to deal with N different
configuration file formats, and N different semantics of how /usr/*,
/etc/*, /usr/*.d interact.
* The administrator isn't required to type directives into a file and
to deal with the fallout of a typo in the directive name.[1]
* Upgrades within a release always work without human intervention.
(=> after we get some experience, they could even be automatic.)
* Upgrades between releases always work without human intervention
unless the feature is completely removed (and in that case the user
will be told before the upgrade  starts).  E.g. configuration and file
formats are transparently and automatically updated.
* The administrator is never required to set up the same option in two
places.  (E.g. joining an IPA domain should automatically configure
all services to use IPA.  Perhaps even have "the services" (see below)
preinstalled and allow the user to enable them, instead of
install+enable as currently.)
* No alerts by a system that works correctly.

This is obviously impossible right now with the full universe of Open
Source services, and with the full configuration possibilities of
them.  However, we probably should be able to decide on the major
functions (HTTP, mail, DNS, ... == "the services" above) and build
front-ends with such fully automated semantics for them (something
like Yast keeping primary configuration in /etc/sysconfig in a common
format, and using that to control the services' natural
configuration).  With the infrastructure built, other applications
that are not "the services" could join.

Even in this more limited format, it would be a long-term project and
a non-trivial amount of work.  Is this direction achievable and
interesting to the WG?
    Mirek

[1] Yes, this is essentially calling for abolishing schema-less text
files as the primary storage mechanism (but not necessarily as a
configuration editing mechanism for those who really want to use a
text editor and shell to modify them).  I'm firmly convinced that we
need a common configuration semantics and a common, reliable way to
edit the configuration from a tool that is not a general text editor,
and we can't get that by taking the union of all features of all
existing text configuration file formats.