Meeting Summary / November 12, 2013

[Máirín Duffy]

Hi folks!

Below find a summary of yesterday's meeting. You can also read it in
blog format at http://fedoraserver-wgblog.rhcloud.com/?p=16 .

Below the summary, you'll find the meetbot links if you'd like to read
the raw logs.


Meeting Minutes
===============

Here’s a run-down of today’s Server Working Group meeting:

Agenda
======
* Can a single server have multiple roles?
* Installation of base + roles


Can a single server have multiple roles?
========================================
This topic discussion covered the following points:

* We agreed that a single server should be able to serve multiple roles.
* Testing combinations of roles on the same server will be tricky. There
are some known combinations that will not work (for example, FreeIPA
isn’t compatible with mod_nss.)
* We’ll start with basic, single server roles, and over time we will
adde tested combinations. (All agreed.)

“A server having multiple roles could be as simple as “In my
cost-constrained office, I want my domain controller to also be my email
server,” said sgallagh.

I pointed out there were some concerns about that approach last week.

sgallagh responded, “There was concern about being able to test such
things.”

“Yeah, testing can be a big pain if we have 10 featured things and you
can install any one or any combo of them,” said nirik. “But we could
also just say ‘we test each of these things alone, let us know if they
interact poorly.’”

mitr asked sgallagh, “We aren’t ordinarily concerned about testing a
system that has both Firefox and Devhelp installed; isn’t this the same
thing?”

“At first glance I agree with you,” replied sgallagh. “but with server
applications they can sometimes interact with each other in odd ways.
Such as requiring mod_nss vs. mod_ssl in apache (to pluck a known
example out of the air.)”

“Server can have one or more roles,” added Viking-Ice. “There is no
doubt about that.”

“But we need to be clear what we test in that world,” said nirik.

“Yes,” agreed mitr.

sgallagh added, “As I said above, I think it must be possible, but we
can probably get away with stating that we only test each role in a vacuum.”

“We chose a role and we test cover that role,” said Viking-Ice.

“Alternatively, when/if we get automated tests,” said mitr, “doing a
‘full install’ and running all the tests on it should be reasonable –
but let’s not commit do doing manual work twice.”

Evolution asked, “Do we document roles that obviously conflict?”

“I would say not,” answered Viking-Ice.

“Well in some cases you can in some others you cannot,” simo answered.
“In freeipa we use mod_nss… so you won’t be able to use it with another
program that depends on mod_ssl. That may change in time to avoid
issues, and fedora server contribution may actually help smooth those
issues in some cases.”

sgallagh also answered, “That would still require testing all of them
together to learn whether they conflict.”

“We can only guarantee what we test,” said simo. “So perhaps we should
start just with bare roles, and in time add explicitly tested combinations.”

mizmo brought simo’s proposal to the table and it was supported by everyone:

*** Regarding multiple roles on one server, we will start with just bare
roles, and in time add explicitly tested combinations. ***


Installation of base + roles
============================

mizmo brought up, “It looks like another concern from last week’s
minutes, about multiple roles per server, was how to install the server
that way.”

“You install the base server ( which I call FOSSP, )” replied
Viking-Ice, “then install one or more roles.”

“Yeh, that makes sense to me,” replied mizmo. “The anaconda UI actually
makes this pretty easy… you can set various roles to be compatible /
incompatible and let users select.”

sgallagh asked, “By way of comps groups?”

“Yep,” mizmo replied.

“That’s the way to go in my opinion too,” said nirik.

mizmo added, “If we have a better answer to comps groups or want to
expand on them or fix them, though – it should be possible, I think.”

“I think we can agree on this “FedoraOS Server Platform ( FOSSP ) is
made available with or without an predefined server role,ready to use ks
for traditional method of installation,directly into an isolated or OS
container or as an whole-disk images to be used in private/public cloud
as instance-store image or standalone server in the cloud itself.”

“Way too many decisions in one sentence,” said mitr.

nirik responded, “-1 on kickstarts.”

“I think kickstart is too implementation-specific, although it’s
obviously going to come into play,” added mizmo.

“Kickstarts should be supported but not required,” simo added.

sgallagh asked nirik, “Can you expand on that?”

“Kickstarts only work at install/create time. You can’t for example
install foo and then decide to add role bar later,” said nirik.
“Kickstarts contain too many site-specific items.”

mizmo responded, “If the role was a comps group, you could though,”
pointing out how a role could be added on later.

“Yes, which is why I think it’s a better solution,” said nirik.

“So you’re just opposing pre-generated kickstart files we make
available, rather than ‘don’t use kickstart to set up servers,’ I
assume?” sgallagh asked nirik.

“Yes,” nirik replied.

“Nirik,” said Viking-Ice, “We install either the base server or base
server + 1 ( and later as has been decide ) or more roles. We test this
as is as it comes from us.”

“I’d like to see it in anaconda/yum groups personally,” said Evolution.
“Kickstart recipes would be good, but as a community thing maybe outside
what we’re doing here.”

mizmo added, “I don’t think we have a good GUI way to install groups
post-install, though.”

“That ‘needs to change,’” said mitr. “Mind, it’s not a matter of adding
a comps group only; installing a server role should also allow easily
invoking a GUI to set up that role as a group.”

“That’s one thing actually I want to talk using Cockpit for, when that
project finds its feet a bit,” sgallagh pointed out.

“Which brings up for me how we still need to discuss personas :) ” said
mizmo.

Viking-Ice replied, “I think we can drop personas and target and just do
the prd’s for roles.”

mizmo questioned Viking-Ice, “Then how do you know how to make the
decisions if you dont know who the product is for?”

“Well, roles should be targeted at personas,” sgallagh said. “Where the
persona may simply be “Admin that needs to run a mail server. Or more
likely “Admin that needs to be able to manage a groupware suite.”

“Right,” said Viking-Ice. “Our audience are administrators, and we do
not care at which level or how experienced they are.”

“I think we should actually be aiming to target a more junior admin than
we traditionally have,” responded sgallagh.

“I think it would be good to be clear about our targets,” added nirik.

“What kind of personas do you have in mind?” asked simo. “Unix-savvy
admin vs clueless admin? Are there any other?”

mizmo replied, “Let’s pick that up after the install base + roles topic.”

sgallagh said, “For post-install, I was personally envisioning doing
something like canned ansible recipes (formulas?)”

“Again, tho, the problem is that they are very site specific,” responded
nirik.

“BTW you can add an role later ( After install via yum or dnf foo )”
said Viking-Ice.

nirik replied, “If they are comps groups, sure… but if they are, why not
use that in the installer to install whatever the person wants? Or they
can write their own kickstart.”

“Can we agree on goals instead of technology first?” asked mitr. mizmo,
sgallagh, and simo agreed to this.

Viking-Ice continued, “We provide vm’s and best out of the box
experience ( which can be read as few steps to get it going.)”

“I think we need to decide only if we want to make it easy to install a
‘role’ and when. Only at anaconda time or at any time?” said simo.

mitr proposed a couple of goals:

* “Goal 1: automated (“mass”) install within a larger Linux
infrastructure (e.g. PXE is an option, may have LDAP/IPA.)”
* “Goal 2: manual install without a supporting infrastructure (e.g. the
very first Linux server).”

After that we ended up hopping on an etherpad (via piratepad.net) and
working through some goals. We got a good set of initial goals and
deferred some goals for later discussion, then promoted the document to
the wiki, here:

https://fedoraproject.org/wiki/Server/Proposals/Server_Roles/Installation_Goals

We ran out of time and decided not to continue past the original
allotted time this week. Further discussion about server role
installation goals will take place in this thread on the mailing list.


Meetbot Minutes:
===============

Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting-1.2013-11-12-16.02.html

Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting-1.2013-11-12-16.02.txt

Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting-1.2013-11-12-16.02.log.html