Today was the third meeting of the Fedora Server Working Group!
How to Get Involved
Here are the various resources now affiliated with the Server Working Group that you can use to follow along or participate:
- IRC Channel: #fedora-server on Freenode IRC
- Mailing List: server at lists.fedoraproject.org
- Wiki Page: https://fedoraproject.org/wiki/Server
Here’s a run-down of today’s Server Working Group meeting:
We didn’t have a pre-set agenda, so we came up with one on-the-fly.
- 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_ssl since it requires mod_nss.)
- We’ll start with basic, single server roles, and over time we will add 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,” said Viking-Ice, “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:
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.
Other Ongoing Discussions
These are other discussions the group has or needs to have, and will likely end up on next week’s agenda:
- Goals for Server Role Installation (group)
- Personas (mizmo)
- Server Lifecycle Proposal (sgallagh)
- Updates and Testing Proposal (nirik)
- Server Role List Proposal (Viking-Ice)
Here is the official meetbot meeting minutes with links to the full raw log: