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-mee...
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-...
On Mon, Dec 9, 2013 at 3:54 PM, Máirín Duffy duffy@redhat.com wrote:
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-mee...
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
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:
Networking config: Primary IPs? Gateway? Additional IPs? DNS? 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: http://technet.microsoft.com/en-us/library/hh831669.aspx
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. https://access.redhat.com/site/documentation/resources/docs/en-US/Red_Hat_En...
Screenshot of Windows DNS Manager GUI: http://www.azurecurve.co.uk/images/posts/1112/DNS_CNAME/DNS_CNAME_1.png
Windows does use a common UI in MMC for managing. From "computer management" you can view logs, manage services, hardware, etc. etc. http://teamapproach.ca/trouble/images/ComputerManagement.jpg
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.
Dan
server@lists.fedoraproject.org