Meeting Summary / December 3, 2013

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-... 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-meeti...