Meeting Summary / December 3, 2013

[Máirín Duffy]

Sorry for the lateness of this. I had a very busy week.

Blog post is here:
http://fedoraserver-wgblog.rhcloud.com/fedora-server-working-group-dec-3-meeting/

Copy/pasta below for your convenience:

Agenda

Our agenda was set ahead of time on the mailing list after an active
discussion on the call for agenda post.

- Adam Williamson Confirmation
-  Discuss Role Implementation
- PRD (we didn’t get to this topic)

Members Present

    sgallagh
    nirik
    mizmo
    simo
    adamw
    mitr
    Evolution
    davidstrauss

Adam Williamson Confirmation

As discussed at last week’s meeting, sgallagh approached the Fedora QA
team to seek a nomination for a new Server working group member to fill
Viking-Ice’s vacated spot. Adam Williamson volunteered to fill the
vacated seat. This was supported all of the by the seven present voting
members with no disagreement, so adamw is now the newest Server working
group member.
Discuss Role Implementation

This conversation was very dense and meandering, and after spending a
couple of hours trying to turn it into a useful readable dialog I
decided it’s going to be more valuable to just summarize it up,
point-by-point. That summary follows.
Cockpit

stefw and andreasn participated in this discussion from the perspective
of the Cockpit project – a server console UI. They have been thinking
about “ways to make more advanced server roles (sorta like some of the
wizards in windows) discoverable and accessible via cockpit. [To] have a
nice way to configure one of your servers as a Freeipa server, for
example, is a goal of ours. Or to have a way to configure a server as a
monitoring server.”
Server Role APIs

There was some discussion about designing an API – stefw cautioned the
group against designing a generic server role API from the bottom up and
instead recommended looking at how people should interact with it first.

sgallagh noted that OpenLMI could be a good abstract API to use.

davidstrauss remarked that [cockpit?] seems to map to systemd and thus
it isn’t generic.

mitr pointed out that based on server list discussions:

    UI is important
    Automated installations are at least equally important.
    One possibility that was suggested is to have a single
‘configuration’ for a role and to be able to ‘(re)apply it,’ i.e. not an
API to change a value, but to remove/read a role with a new
configuration (retaining data, of course).”

simo is fine with enabling cockpit and OpenLMI, but isn’t sure it’s a
good idea to have Fedora Server rely on them.
Configuration

Some suggestions that were brought up:

    Move most of the package and operational config to post-installation
so we can better support remote tools. (davidstrauss)
    We should do as little configuration as possible by default, with
the option for “advanced” knobs post-deployment. (sgallagh)
    Install all packages, install config, and bring up a ‘standard’ (I’m
not talking static. I mean, ‘ask for the minimum information necessary
to reasonably install) config of the service, and then allow users to
tweak after the fact. The way that most boxed server vendors work.
(sgallagh)
    Without a lot of info from the user up front (nirik)
    It’s a spectrum from: just install the needed packages and user goes
from there all the way to: install all packages, install config and
bring up a ‘standard’ config of the service… (nirik)
    For most networking services, config generally needs to be delayed
anyway because you need hostnames and sometimes IP addresses to be the
final ones, anyway. A lot of software can’t be correctly tweaked after
install easily. (simo)
    My vision of a ‘default install’ for a server OS would be basically
Fedora’s current minimal. (adamw)
    I would like to see minimum be truly minimal though. Not minimal for
basic. but absolute bare-bones. (Evolution)
    We could work with package maintainers to just have the package
provide whatever default ‘standard’ thing to tweak out of the box? (nirik)
    Should we ask at OS install time or at firstboot time? (simo)
        That’s the part we need to figure out and the part that I was
talking about having an ‘API’ for… To configure it for “default” use.
I’m not committing to a complete configuration API right now. (sgallagh)
    Basic configuration should be able to be performed by the installer
or a management console like cockpit. (sgallagh)
    stefw is hoping that openlmi will provide the scripting and cockpit
the UI, and cockpit can use OpenLMI as appropriate.
    Scripts are complex, but using scripts to manage configuration
sounds like debconf, and it seems debconf is a model we’d like to avoid:
        The scripts create a lot of maintenance overhead
        It breaks automated config tools because of how its interactive
configuration works
        It starts things after installation, without using the config
you wanted for initial startup.
        It’s integrated with the packaging system. Package installation
and configuration are two very separate steps.

Even with the bulleted list approach above, you can see how this was
kind of all over the place. :)
Taking a Step Back

I tried to come up with a rough long-term vision for how server role
installation and configuration would work based on the discussion:

    “When you install a role, it comes prepackaged with a set of sane
defaults which you can configure post-install.”

davidstrauss noted that it’s already 95% of the case. I asked how is
this vision solving anything, and stefw said that sane defaults don’t
come with many packages. “Fixing up software and packages so that
they’re ‘roleable’ is a big part of this,” he also said.

adamw also suggested,

    “It sounds like we’re discussing some sort of distro-owned
configuration/wizard/helper layer between the default configuration we
set in packages and whatever configuration guides/tools the upstream
software provides, which I thought was a business Fedora had been trying
to get out of.”

sgallagh explained,

    “We want to behave more like Windows Server does here: If someone
tells Server Manager that ‘that machine over there is a domain
controller,’ it gives you a wizard to set up the basic information and
then later allows you to tweak it further.”

I brought up that I recently tried to set up postfix and it was a bit of
a nightmare, and I wasn’t sure how you could configure it to run
out-of-the-box when so much of the setup was specific to a given network
/ domain.

“You cannot solve that problem w/o building something like kolab,” said
simo. “I do not want to get Fedora in the business of building in
tightly integrated roles, because we will fail.”

simo, mitr, and sgallagh agreed that, for at least the short term,
packaging only simple roles or existing integrated roles is something we
should focus on, and we shouldn’t try to integrate non-existing roles.

davidstrauss suggested using containers to allow tight integration
between daemons. “[It's] easy to run into conflicts between how one
‘app’ wants DNS configured and another one does.” mitr disagreed with
the container approach, though, “containers do pretty much nothing
valuable to the user in this aspect – isolation is an aspect of
reliability, not an end-user feature.”

“I’m actually saying with the container stance that we should punt on
the problem,” said davidstrauss. “I don’t think we’re equipped to do the
integrated recipes.”

There was some discussion about implementation – OpenShift gear recipes
and docker were brought up.

“I’m very anti-NIH. Proudly invented elsewhere should be a goal of
ours,” said davidstrauss, and the whole group appeared to agree.
Vision Statement

Post-meeting, I expanded the vision statement for role installation
based on the above discussion,

        Roles will be maintainable objects in a repo managed with Fedora
        maintainer standards, integrated & coherent for things like email
        server, groupware, etc.
        Users can select roles to add to a system, and would be provided
with
        a (wordpress first-run like) wizard for some initial information and
        they’ll be given a working server using sane defaults.
Optionally, the
        user should also be able to deploy the role in a mass deployment
without
        having to interact with the wizard.
        The configuration should be able to be modified post-install
(but not
        necessarily via GUI right away; it’s hard to commit to this.)

How to move forward

Generally everyone seemed to suggest that we need to choose 1-3 roles
for the first release, and learn the best approach from exploring them.

simo also suggested that someone needs to take a stab at proposing a
clear view and provide a well-thought-out example. sgallagh volunteered
to do this using FreeIPA as the example, which he has already posted.
Meetbot Minutes

Here is the official meetbot meeting minutes with links to the full raw log:

http://meetbot.fedoraproject.org/fedora-meeting-1/2013-12-03/fedora-meeting-1.2013-12-03-15.59.html