Meeting Summary / December 3, 2013
by 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-...
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...
10 years, 4 months
Agenda for Server WG Meeting (2013-12-10)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
No one else chimed in, so the only thing currently on the agenda is
the PRD (which is important!).
I'm still working on the FreeIPA straw-man role; other obligations at
the day-job interfered. I don't know if I'll have anything ready early
enough for people to digest it before the meeting, but I'll try to
have something sent out today anyway.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKmDu8ACgkQeiVVYja6o6P3+QCcCbX/O3QIo1cSFeke/U4ZqHcL
BhkAoJt0/WCqm7r224R762BAmXd2laeq
=VkSC
-----END PGP SIGNATURE-----
10 years, 4 months
Call for Agenda (2013-12-09)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm planning to have some mock-ups and a user-experience story ready
on Monday to use a straw-man for the Role discussions, so we'll
probably want that on the agenda.
Other than that, with only three meetings before the PRD due date, we
probably need to really focus on what we want in it.
I'd suggest that we define the important sections and task individual
members of the group to write them up for next week.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKiGmoACgkQeiVVYja6o6M8UACeIT8UufhpAVK7BxUi2NjAGVb8
dH8AniP4vBBwPvQ0OezY9aWspXn9pTkr
=BGqF
-----END PGP SIGNATURE-----
10 years, 4 months
Draft Server Roles Vision Statement
by Máirín Duffy
Hi :)
Here is the draft server roles vision statement we came up with in
today's meeting:
The vision for role installation (so far)
-----------------------------------------
- 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 [1]) 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.)
Logistics
---------
- We are concerned about the manpower required to maintain framework /
configs for this role installation vision.
- We very much prefer to find pre-existing projects / technology to make
role installation possible, which should help alleviate concerns about
manpower.
- We will need maintainers for the roles.
Implementation details to be sorted out
---------------------------------------
- How the interactive wizard would work / what upstream it would use.
- How to allow non-interactive input of initial wizard config questions
to enable unattended / mass deployment.
~m
[1] http://www.wpstuffs.com/wp-content/uploads/2012/12/setup_wordpress.jpg
10 years, 4 months
Making migrations common (and not scary)
by David Timothy Strauss
(Pulled out of the meeting thread)
We've been talking about extended lifecycles as an admin-friendly
direction to take Fedora Server. But, I think we should consider
spending more resources better-supporting migrations to new servers,
including OS version bumps. Administrators often favor long lifecycles
because this process is usually tedious and error-prone. The more we
make this part of normal operations, the more we make super-long
lifecycles unnecessary.
It's probably ambitious for a first release, but it would be amazing
to have good tools for vacuuming over services, containers, and VMs.
The latter two already have tooling, but it would be super cool to
abstract it into a general utility for migrations. It could enumerate
migration-enabled resources. Integration with RPM verification could
list configuration that's not possible to automatically migrate.
10 years, 4 months
Regret not to attend today
by Truong Anh Tuan
I am getting on train back to my home now.
I will try but I am not sure if I can connect on the train. I will see the logs.
Kind regards,
Tuan
10 years, 4 months
Agenda for Server Working Group Meeting (2013-12-03)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(Copying from the other thread for posterity)
Adam Williamson has expressed an interest in filling the vacant seat
on the Server Working Group. We should vote on his confirmation.
Also, Stef Walters mentioned to me yesterday that he would like to
discuss some of the requirements on the role implementation at the
meeting.
Given Máirín's comments about the Personas, we may want to keep those
out of the meeting and address them via the mailing list this week.
So right now, I have:
* Adam Williamson Confirmation
* Discuss role implementation
* Start formulating the PRD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKd6CsACgkQeiVVYja6o6NAWwCeOvW+rL+zk7hlYtnw0vJ1HFmB
H60An3rrSBH1freaNDsd/oNKzd2/73s2
=+STg
-----END PGP SIGNATURE-----
10 years, 4 months
Call for Agenda (2013-12-02)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry for the late agenda call, folks. The holiday in the US threw me
off this week.
My guess is that we want to continue honing the Personas this week.
Other important topics?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKcguMACgkQeiVVYja6o6ORHwCfRdbfY8rQPzmmpYIhsyn7AE5R
WVEAnR2xIOXpFFC88X3cHxEbkiJ5UnJX
=pQx8
-----END PGP SIGNATURE-----
10 years, 4 months
