On Mon, Dec 9, 2013 at 3:54 PM, Máirín Duffy <duffy(a)redhat.com> wrote:
Sorry for the lateness of this. I had a very busy week.
Blog post is here:
Copy/pasta below for your convenience:
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)
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
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.
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
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.
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.
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
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.”
“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
“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
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.
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
a (wordpress first-run like) wizard for some initial information and
they’ll be given a working server using sane defaults.
user should also be able to deploy the role in a mass deployment
having to interact with the wizard.
The configuration should be able to be modified post-install
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.
Thanks for the summary Máirín.
I like the idea of having UI based wizards for "roles" a la Windows
server. I think it's a great idea. I spend days at a time learning a
new "role" or often forget how to do something.. like getting a
website up in apache or nginx.. and then getting PHP working.
Constantly having to look at error logs and googling to see what I
forgot or how I messed up each time.
mitr made a great point in that UI will be very important here, and I
do think a common UI will be crucial. Another thing is that we don't
want to end up designing something like plesk or cpanel. They have bad
repuations for good reasons.
I really like the way Anaconda on RHEL/CentOS basically asked you
these sort of role questions in a way. But I didn't like how when I
chose an option there were like 75 sub options for something. Most of
which I didn't even know what they did.
I think we should put out some kind of "most common goals/objectives"
type of list together and a "most common type of configuration" list
together as well.
Here are some off the top of my head:
Written to config file for you. (Kind of like system-config-network)
Example role: web server
Question: nginx, lighthttpd, or apache?
PHP support? Y/N
Perl-CGI support? Y/N
Python support? Y/N
Create a site now? Y/N
Hostname of site? Y/N
Install SSL cert now? Y/N
"Site created! Config written."
"Want to create another site?" Y/N
Example role: Mail server
Question: postfix, sendmail, or qmail?
Smarthost (insert explanation of smarthost here)?
Example role: Database server
Question: Maria (MySQL), Postgresql, or MongoDB?
Create your first database now?
Configure backups now? Simple? Full?
Configure backup schedule now?
Example role: DNS server (this probably requires a GUI in itself..
windows GUI is great and should be looked at.)
Example role: High Availability/Clustering
Example role: Load balancer
Example role: Backup server/Dedupe box
Example role: Firewall
Example role: Build machine
Example role: Print services
Example role: File server/NAS (should support smb and nfs and can be
integrated with print services like Windows)
Example role: 389 Active Directory integration (aka server that syncs
with windows AD for linux AD authentication)
List of Windows Server 2012 roles:
Windows server also does further configuration of roles via role
services. For example instead of having a question for PHP support in
a webserver it can be done the way role services are done on Windows.
Screenshot of Windows DNS Manager GUI:
Windows does use a common UI in MMC for managing. From "computer
management" you can view logs, manage services, hardware, etc. etc.
So I guess the question really is "How far are we willing to go with
this" and "How much time do we want to spend on it?"
Regardless, I think these enhancements are a long time coming.