Monthly Archives: November 2013

Fedora Server Working Group: Nov 26 Meeting

Fedora Server Working Group Logo

Today was the fifth 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:

Meeting Minutes


Our agenda was set ahead of time on the mailing list after an active discussion on the call for agenda post.

  • Select a new member of the Working Group
  • Personas

Members Present

  • sgallagh
  • nirik
  • mitr
  • simo
  • mizmo
  • davidstrauss
  • tuanta
  • Evolution

Working Group Member Selection

Jóhann (Viking-Ice) decided to step down from the server working group. So the server working group needs to select a new working group member. As mitr pointed out, our charter says we should choose from “from the active Fedora Server community” but the group hasn’t been around long enough to build up an active community.

Since Jóhann represented the QA community in Fedora, we agreed on the following:

  • We will ask the QA community to recommend someone from their ranks.
  • If no one from QA steps forward, we will put out a general call, particularly to those who previously volunteered.


Most of the meeting time was spent on discussing personas. I (mizmo) gave a status update on where the personas are at right now:

  • We have a working personas document available at: It’s based on the personas nirik suggested at last week’s meeting.
  • We have one sysadmin interview completed to help inform the personas. mizmo and sgallagh interviewed kdetony last week. He is a sysadmin for a large company. (The interview notes are now available in the wiki.) mizmo will interview davidstrauss too when he returns to the US.
  • sgallagh and mizmo basically put together a FAQ on personas as well (I just put it up on the wiki now.)

A quick review

Evolution missed the last meeting, so we filled him in on the point of personas and how we’d go about using them. I added our answers to the persona FAQ so if you are curious about these things please check that out.

“I like the general concept,” said Evolution, “so long as we don’t get caught up in arbitrarily pigeon-holing things because of this.”

“We all agree on that score,” sgallagh assured him.

Persona order?

Nirik also had a great question about whether or not personas have an order to them; they can – for example, we can define a couple of primary personas, have secondary personas, and maybe anti-personas (we would explicitly not cater to the needs of the anti-personas, but could define them for clarity.)

The personas from the first draft

So next I walked folks through the three personas we have:

  • Senior sysadmin / nonprofit org / she’s classified as ‘MacGuyver’ because they don’t have a lot of resources but try to get a lot done
  • Server app developer / freelancer / (no nickname yet)
  • Junior sys admin / huge company / lots of resources available (no nickname for him yet either)

What does junior mean, and another persona suggestion

davidstrauss asked, “What makes the third one ‘junior?'”

“He might not have as much decision-making power,” I (mizmo) replied, “He’s not the team lead or anything like that. so he may be stuck with decisions made over his head.”

“It seems strange to couple abundant company resources with the ‘junior’ guy,” davidstrauss responded.

I replied, “Well, not necessarily. E.g., if he needs more hardware he probably won’t have a hard time getting it, but he’s not going to be able to change the bureacracy at his org.”

“Well, I guess I’m the contrast to that persona, anyway. We have lots of resources, and I’m CTO,” said davidstrauss.

“I think you would be an excellent additional persona,” I replied. “I would probably nickname your persona ‘decision maker.'”

davidstrauss answered, “I don’t really care if it’s me, but we need someone with resources + power.”

“Yes, a decision maker is an important case,” mitr added.

Going meta

sgallagh suggested that we add a persona for folks creating a new server role for Fedora Server. This would be a kind of meta persona – a person who contributes to Fedora by putting together a role for the server platform product. We’ll add it as a secondary persona.

The question this persona might help answer, as posed by davidstrauss: “How does one create a service that plugs nicely into Fedora?”

Developer vs. DevOps

“I do agree we need a developer persona (particularly for the requirements on languages and deployment),” mitr pointed out. “Can we clarify that Server is not the OS one uses to actually develop the application (i.e. run Eclipse / ask on stackoverflow …) – that should be Workstation [… which requires inter-WG agreement on the languages and deployment mechanism).”

nirik added, “Yes, but we shouldn’t ignore that case… they need to install server software to test, etc.”

I (mizmo) took the action item to modify the developer persona accordingly.

I also asked, “Should we have a devops persona too in addition to the developer?”

“I thought that was what your developer persona was, there,” sgallagh responded.

mitr asked, “What would be unique about devops? Ability to deploy and to monitor should already be there.”

“We could make him devops then,” I said, “I think Ijust need more info about how the guy would work. I don’t know enough about it. E.g., does a devops person get paged at all hours when there’s an outage?”

mitr said, “I’d slightly prefer not restricting ourselves to devops (multiple platforms, and speed to deploy are equally important when deploying a 10-year old J2EE application), but I don’t feel strongly about it.”

“The primary difference with DevOps,” sgallagh explained, “is the concept of ‘Mean time to recovery’ is more important than ‘Uptime.'”

“Does devops necessarily mean a smaller organization?” I asked. “Because I don’t know how you’d have them combined into one role for a huge app like the one I’m thinking of.”

Simo responded, “Well, devops people would say no, but in reality I see real devops only in startups. :)”

“Devops kind of captures nicely “the Ruby problem” (sorry, I’m unfairly picking on a single language for simplicity),” mitr added.

I asked, “What’s the ruby problem?”

“The ruby problem is mainly ‘the bundling problem’ rehashed,” sgallagh answered. “Except with a community that has no stake in backwards-compatibility (in the general case.)”

“What sgallagh said, + the culture that ‘that’s how things are done.'” added mitr.

To confirm my understanding, I asked, “So with ruby you need devops, because the platform isn’t backwards compatible, so you need a developer to port things forward if something goes wrong because of a bug in the platform or whatnot?”

“Precisely,” sgallagh answered.

simo added, “It is not just ruby.”

“Right, ruby is just a representative example,” sgallagh said. “This is true of a lot of Java shops too.”

“It is also: oh cloud provider X we use is going to change API in 10 days,” explained simo. “Need to develop a different connector for the production servers ASAP. Language really doesn’t matter”

“And Google APIs…” added sgallagh. “So it’s really about resiliency not just of the service but also the deployment itself.”

Simo explained further, “It’s about people using *new* platforms that keep changing and shifting all the time. They use so much of *everything* it is all in costant motion.”

“Well, it’s also about a perception change,” sgallagh added. “That absolute stability is not as important as rapid recovery.”

davidstrauss said, “It’s part of the perception change I’m referring to in the migrations vs. support duration [thread]. How easy is it to keep the app on a supported foundation? *versus* How long can the foundation we’ve deployed to remain supported?”

“It is a lot about automation,” said Simo, “because devops will redeploy a lot. A lot more than traditional ops used to.”

Nirik also illustrated the point, “‘Thing x is hard and we only do it once a year, so, lets do it 10x/day now and fix all the problems so that we can keep going.'”

“Right, the devops folks pretty much live in the ‘livestock’ side of things, except possibly for their hypervisors,” added sgallagh, referring back to the analogy that some servers are treated as expendable (like livestock), and some
are given names and fixed up when they get broken and are kept around long-term (like pets.)

“They concentrate on the changing pieces but absolutely rely on the stable infra as well,” simo said.

I asked, to confirm, “So devops people are more automated, the traditional people are more ‘omg don’t break it?'”

“That’s a pretty fair analogy,” replied sgallagh.

So we concluded that I’d make the developer persona more ‘devoppy,’ now that I had a better understanding of what that meant.

Where does Server end and Cloud begin?

One thing that came up at this point in the conversation was the line between the Cloud product and the Server product.

“When it comes to server and cloud usage, I want Fedora to leapfrog the current popular choices philosophically,” said davidstrauss. “Our competition is, in some ways, CoreOS more than Ubuntu.”

nirik added, “I think we can add a lot of value in standardizing/best practices…”

“Let’s also not get in the Cloud group’s way too much either,” sgallagh pointed out. “I think we probably want to be focusing on the infrastructure to support their product. Fedora Cloud is likely to be Fedora’s answer to CoreOS.”

“I’d generally prefer if a Cloud application and Server application were bit-for-bit the same (but it hasn’t been discussed yet,)” mitr added. davidstrauss agreed.

“To be honest, I see less and less separation between server and cloud product,” said simo in response to sgallagh. “I wonder if they really will be that different if we keep pushing hypervisor stuff that way.”

“I always thought cloud os would care about guests more than bare metal,” simo said.

Evolution responded, “There’s a large amount of crossover in the two.”

“But the guests are often-times running the server bits we’re interested in,” replied Evolution.

simo in response said, “I wonder if it really make sense to have separate stuff in the end.”

“We deploy Fedora to bare metal as a container host,” davidstrauss explained. “Once companies like GitHub, Etsy, etc. grow to a certain point, they often substantially leave ‘cloud’ for bare metal. And once they leave cloud, they either deploy to hypervisors on their own hardware or something like the “guest images” to bare metal directly.”

sgallagh said, “Whereas our position is to deliver sturdy infrastructure both for traditional roles and to support Cloud deployments.”

simo replied to davidstrauss, “True, many company have mixed environments, with in house clouds + overflow on public clouds after some time.”

“Some companies opt to run their own clouds. Others move to PXE deployments and similar,” responded davidstrauss.

Traditional Developer Persona

“Did anybody have a chance to read through some of the stuff on the developer persona? I kind of really just made it up but I don’t know if I was getting at the wrong thing,” I asked. “E.g., under frustrations: ‘Spending cycles porting code to an endless array of platforms – it’s time-consuming and uninteresting work,’ but I guess a devop wouldn’t do that?”

sgallagh answered, “No, devops would pick a minimalist platform and just VM/Containerize it.”

I asked further, “Do we care about devs/admins who would need to do porting work like that on a server?”

“Traditional app developers will need to be served, yes,” sgallagh answered, “The Oracle DBs and SAPs of the world, for example.”

I asked for more examples of traditional deployments, and got the following:

  • Domain controller
  • DNS server
  • Email infrastructure
  • File server
  • Storage cluster
  • Office proxy
  • Office DNS and web proxy

Personas and timelines

“We probably should try and finish personas in not too long… given our short timeframe to come up with deliverables/document,” said nirik.

“I think we’re pretty close,” I pointed out. “I didn’t see a whole lot of contention here about the ones we have so fair, just some refinements / expansion.”

As sgallagh proposed, I’ll try to have the personas document ready to be voted on December 10.

Meetbot Minutes

Here is the official meetbot meeting minutes with links to the full raw log:

Proposal Announcement: Fedora Server Lifecycle (stable and development)

This is the first of what should be an ongoing series of blog entries describing the assortment of proposals up for discussion within the Server Working Group. In general, these will be proposals that have been brought to the mailing list at one time or another. We will be summarizing and posting them on this blog to provide wider dissemination of knowledge. Comments on this and future proposals is best provided to the Fedora Server mailing list, but we will monitor comments on this blog and attempt to incorporate them into the discussion as well.

The following is a proposal, not an accepted plan of action.

This blog post is copied from which is the official home of this proposal and will always provide the latest and most accurate information on it. The images provided are copyright Máirín Duffy and licensed CC-BY.



This proposal comes from the following thread started by Stephen Gallagher on the server mailing list:

Thoughts on Fedora Server lifecycle

A relevant earlier proposal that is similar is Tom Callaway’s Overhauling the Fedora Release Model talk from FUDCon Lawrence in January 2013.


This proposal is for a lifecycle of eighteen months (with slight extensions for slippage) as follows:

  • We will start with Fedora Server 1.0 (rather than Fedora Server 21).
  • We would build the Base Design as Fedora 21, Fedora 22 and Fedora 23 following mechanisms not terribly dissimilar to the present-day model.
  • We would then create the Fedora Server atop this, delayed by a small amount < 1 month).
  • We would use the latest Fedora Base bits as the platform and sync our pieces atop it at regular intervals, aiming for a finalized release every eighteen months.
  • Up until the final release, each N preview release should be just a snapshot matching EXACTLY the Fedora Base release at that time. It should be usable (but probably won’t get any extra QA time over the Base release). Then at the N.0 final release, it should get branched away and kept more tightly controlled. This doesn’t mean that it can’t get updates out of the Base branches, but they should be merged in when they’re ready, not blasted in from the firehose.
  • Each N.0 release essentially goes into maintenance mode at the moment of it’s stable release. Real new functionality should head to N+1 previews and only get pulled back to N.x if it makes sense and someone is willing to do the work.


Detailed Walkthrough Of Timeline


Source SVG

Continue reading

Fedora Server Working Group: Nov 19 Meeting

Fedora Server Working Group Logo

Today was the fourth 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:

Meeting Minutes


Our agenda was set ahead of time on the mailing list.

  • Goals for Server Role Installation
  • Personas
  • Server Lifecycle Proposal
  • Updates and Testing Proposal
  • Server Role List Proposal
  • Installation Roles vs. Post-installation Role Assignment

Members Present

  • sgallagh
  • nirik
  • mitr
  • simo
  • mizmo
  • Viking-Ice
  • davidstrauss

Goals for Server Role Installation

We went over the server role installation goals document that we started in the piratepad last week. Nirik suggested another goal which we put in the deferred list for now:

I wonder: do we want to add: ‘off line’ installs? […] use case would be a secure site that can’t access the internet… they want to install a server + roles without direct net access.

sgallagh remarked that for users in need of this goal, “as a workaround they can always have a local mirror too.”

“… if we support manually-managed local mirrors,” replied mitr. “It’s not a huge problem but worth keeping in mind == adding to the deferred list.”

“As long as you can run mirrors or build custom ISOs, it’s easy,” added davidstrauss.

Nirik also mentioned, “If we support this case we need to make sure those tools work, etc.”

“I have run into problems with mirror support, for sure,” davidstrauss agreed.

As mitr brought up mirror management as an issue here, sgallagh asked him, “Do you want to add mirror management as a deferred goal as well?”

“I view “mirror” as an implementation detail in this discussion => N/A,” responded mitr.

Simo suggested, “Mirror management could be a product role, actually.”

“True,” replied sgallagh.

We agreed to accept the server roles installation goals document.


I posted a link with some introductory information from the mailing list: Fedora Server Personas / Target Users. I also posted a placeholder document on the wiki without much of anything useful in it yet.

“So I don’t think a persona is, ‘person who wants to install a directory server,'” I said.

“Let’s decide here how we want them to appear first and then take the brainstorming to the list,” suggested sgallagh, adding “And should we be deciding on Personas for the Server Platform or for the Roles (I’d say defer the latter).”

“I think they should be much more broad than roles so it’d be for the platform,” I responded.

Simo said, “I think we just need to discuss the logistics of this goal. How many personas? Do we want a hard limit so they are manageable?”

“I think 4-6 is reasonable, better to have less,” I replied to simo.

“I think we need first generic personas,” said simo, “to investigate the interaction with our basic product.”

mitr said, “I’m ambivalent on personas – it’s a convenient way to describe the span of the user base but we need to be careful to avoid unwanted correlations (“installation is only done by inexperienced people” and the like.)”

davidstrauss expressed some concern as well, “I’m not a huge fan of using personas here unless they express something beyond the laundry list of other requirements we’ve been drafting.”

“I think they’re meant to be the litmus test for those requirements,” sgallagh replied. “If a requirement doesn’t solve a problem for a persona, we’re either missing a persona or the solution is out of scope.”

mizmo also responded to davidstrauss, “I would like to use the list of personas to go out and do actual user research, build relationships with a cross-section of the user base we’d like that we can then go back to for feedback on ideas etc. So I’m not talking about personas as a 1:1 with a use case. I’m talking more about personas as the kinds of people who would use or be affected by this product.”

“I guess I’m partly less into them because I’m basically in this group as a persona. :-),” davidstrauss responded. He volunteered to help write up his own persona and be interviewed for that portion of the work.

nirik asked, “So, for example: ‘application developer’ could be one right? someone who wants to build server applications? Or ‘home/small business’ where they are constrained to one server/limited resources? Or ‘enterprise datacenter’ where they want to roll out many server instances and automate.” [as an aside, I missed these during the chat and they are all fantastic examples, and I’m totally going to steal them for the first draft of the personas document! -mo]

“Let’s not start discussing individual proposed personas here, though,” sgallagh said.

At sgallagh’s suggestion, I took an action item to create a template for the personas. I do already have one with Red Hat branding that I will repurpose into wiki format. :)

“Then the idea is that we look at those moving forward to decide things?” nirik asked. “How it will affect them or the ones we care about more?”

“I think this should become the litmus test for anything we put as a formal requirement on Fedora Server,” sgallagh responded, “If it does not address the needs of a defined persona, it’s probably not a proper requirement.”

“Exactly. e.g., this feature is great for persona A, but will it negatively impact persona B’s workflow?” I also answered, “Once we have the set of personas i can start finding folks who roughly fit the roles and interviewing them to get more information about their workflow, etc. and get their feedback on our ideas.”

nirik said, “My one concern is that do we have time to do that? With our January deadline?”

“We have time to write up the initial set of personas, I think,” I replied. “To refine them based on the research will take longer but is not needed by January.”

“Fair enough,” nirik responded.

Viking-Ice asked, “Where do you want to place those personas in the definiton of server roles or in the prd for the applications or…”

“We’re not discussing role personas,” sgallagh answered. “We’ve agreed that those are a separate topic. These are personas for the needs of the platform itself, not the specific services it offers.”

simo added, “Personas are part of the discovery phase to come up with requirements, so it belongs to the discovery phase, before PRD, before Roles.”

“Doesn’t really matter,” mitr also said. “E.g. we can keep them on the wiki and use them for the PRD but not include them in the final PRD.”

Viking-Ice responded, “Yes and the personas for the platforms are administrators.”

“Yes, absolutely,” sgallagh confirmed. “But as we discussed yesterday, that’s not a homogeneous group. We want to define the different types of administrators.”

So the conclusion of this topic is that we’re going to have a set of 4-6 personas representing the types of users who would use or would be affected by the Fedora Server Platform. I will send out a template and some initial draft persona ideas, and everyone on the list will respond on the list with feedback, corrections, and their own ideas for personas.

Server Lifecycle Proposal

We very briefly discussed the following points with respect to this topic (in reference to the Server Lifecycle Proposal):

  • FESCo has a ticket on releases and lifecycles: FESCo Ticket #1202 (from nirik)
  • We do not agree with each other on how the platform is composed.
  • We do not have any idea if the Base working group’s plans will allow us to go with this plan.
  • Package maintainers are allegedly concerned about the amount of work this plan will create for them.
  • We are deferring lifecycle discussions for a week.

Updates and Testing Proposal

This was nirik’s proposal as an alternative to tweaking the lifecycle process.

We skipped the topic: “I’m ok deferring it until we know what we are shipping/doing,” said nirik.

Server Role List Proposal

I took the list of server roles in the server roles proposal document and added Viking-Ice’s list of roles from his working document so we now have one consolidated list of roles.

nirik asked, “So, what are we discussing exactly? the entire document? or just the roles part?”

“I guess we should figure out,” I responded, “1) How many roles will we support initially, and 2) identify which of those roles will be in the initial supported group.” I also found a document where we’d agreed to start with 1 to 3 roles initially and pointed that out to the group, and we agreed to start with 3 and go from there.

In response to the list of items, mitr said, “That’s a fairly comprehensive list of possible items. I’m not sure that all of them are actually roles (e.g. backup, containers may be part of the shared server infrastructure.)”

“‘Failover Clustering Services Server Role’ isn’t a role,” davidstrauss remarked. “It’s something particular to specific other roles. Failover is very role-specific. For example, failover for MariaDB is completely different than for Kerberos or Samba. Throwing in a bunch of cluster/HA utilities isn’t a useful fulfillment for HA needs.”

Viking-Ice responded, “Not really + other OS has those defined as roles.”

“As I’ve stated before as well,” sgallagh added, “I’d rather see a “Domain Controller” role than necessarily an LDAP role.”

simo said, “Some of these roles look a bit too generic to me.”

“Yeah, the “Network Services” role is wrong, I’d say,” sgallagh added to simo’s comment.

So the main concerns over the list of roles was that some were too specific, some were off the mark, and some were too generic. There isn’t a lot of consistency to the level at which each role was written. Sgallagh pointed out, “Let’s not be too harsh all at once, though. This is a good place to start.”

Viking-Ice proposed a way forward, “We really should push the roles through the ‘Server Role Process Agreement’ if the intent is to use the stage gate approach.

“Certainly, we should only choose a shortlist of roles *after* defining personas, right?” asked davidstrauss. “If we’re going to the trouble of defining target users, shouldn’t we use that work here as a tool?”

“That’s ideal,” I responded.

simo asked, “How specific do we want roles to be? For example ‘Lightweight Directory Services Server Role’ seems to be quite specific to a task (although I do not consider samba4 lightweight,) while ‘Network Services Server Role’ seems quite broad and in my view would contain the lightweight services from a semantic point-of-view.”

“I think the first ones we should do should be somewhat generic,” nirik replied, “to cover as many folks as we can…”

Simo answered, “I guess I need an example to understand what that means.”

“I think we really need to talk about personas,” sgallagh said. “We might want to focus first on ‘Things people already want to use Fedora for,’ so that we can improve their experience and use them to expand our influence.”

“That’s independent from the personas to a degree,” said simo.

sgallagh answered, “Not if we select “People currently using Fedora as a server” as one of our targets. :)”

“We could also focus on ‘building blocks’… ie, ‘apache web server’ could be used by many other higher level roles?” nirik suggested.

Simo agreed, “Indeed. Some components can be used by many roles, possibily conflicting roles. So having a ‘Web Directory Services Server Role’ makes little sense to me.”

sgallagh suggested that discussion of specific roles should be taken to the list.

Viking-Ice pointed out, “Well people seem to be fixating on the M$ admin so I defined the roles based in theirs and trust there are few more there that dont make absolutly no sense ;)”

“Well, I’ve mentioned a couple times that our path to wider adoption involves getting people to leave their MS comfort zone,” said sgallagh. “But that doesn’t need to be our only goal, or even in the first set of them.”

simo asked one final clarification question, “Do we define roles based on very generic use cases, or do we want to base them on well-defined use cases?”

“Personas should be abstract and focused on end goals. Roles should be well-defined, supportable ways of achieving those goals,” proposed davidstrauss. “A persona might want an office network server that does DHCP. A role might be a network services server with ISC DHCP, etc.”

“I think that persona is too specific,” I pointed out. sgallagh and simo agreed.

Viking-Ice asked that people read his stage-gate process write-up.

Installation Roles vs. Post-installation Role Assignment

We didn’t have time to discuss this topic.

Meetbot Minutes

Here is the official meetbot meeting minutes with links to the full raw log:

Agenda for Server Working Group Meeting (2013-11-18)

The Fedora Server Working Group will hold its weekly public IRC meeting tomorrow (2013-11-19) in #fedora-meeting-1 on Freenode at 1600 UTC.

The agenda topics for this week are:

  • Goals for Server Role Installation
  • Personas
  • Server Lifecycle Proposal
  • Updates and Testing Proposal
  • Server Role List Proposal
  • Installation Roles vs. Post-installation Role Assignment

Fedora Server Working Group: Nov 12 Meeting

Fedora Server Working Group Logo

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:

Meeting Minutes

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

Members Present

  • sgallagh
  • tuanta
  • nirik
  • mitr
  • simo
  • mizmo
  • Viking-Ice
  • Evolution

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 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:

Meetbot Minutes

Here is the official meetbot meeting minutes with links to the full raw log:

Fedora Server Working Group: Nov 5 Meeting

Fedora Server Working Group Logo

Today was the second meeting of the Fedora Server Working Group!

How to Get Involved

Here are the various resources currently affiliated with the Server Working Group that you can use to follow along or participate:

Meeting Minutes

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


Today’s meeting actually took two hours. We devoted one hour to each of the topics below.

  • Finalizing the Governance Charter
  • Is Fedora Server One Product?

Members Present

  • mizmo
  • sgallagh
  • mitr
  • tuanta
  • nirik
  • Evolution
  • Viking-Ice

Finalizing the Governance Charter

We had a discussion about two pending issues with the governance charter before ultimately approving it. The two issues were:

  • Group Membership – Should the voting members of the server working group should be required to be members of other Fedora teams as specified by their seat/slot?
  • Term Length for Voting Members – Should membership as a voting member on the server working group be unlimited / at will or should there be terms and elections/votes inbetween?

Group Membership

We had a long thread on the mailing list about the group membership concerns brought up at the first meeting. While we reached some agreement in the thread (we will not require any form of experience / proof that a member has experience with server technology to become a voting member of the server working group,) we weren’t able to come to consensus on whether or not voting seats on the working group should be earmarked for members of specific Fedora groups.

So we talked about that last dangling issue first during today’s meeting. I brought it up in this way, “There seemed to be a lot of concern about having chairs represent specific sigs/ other teams in fedora last meeting, I didn’t see that resolved on list.”

mitr replied, “Seems to me that way as well. I’d still prefer not having reserved seats; we can set up liasons when/as much as necessary.”

nirik agreed: “…involvement from many parts of the project is vital, but not sure that each group needs a voting seat…”

Viking-Ice expressed concern that if the seats are just liasions with the other groups and not members of the other groups, that the work we need those other groups to do won’t necessarily get done. Conversely, nirik was concerned that, “groups may not want the time/involvement that a voting seat would be… they just want to know/help where it affects their main focus.”

We came to agreement after this discussion that it made sense to drop the group mappings for now, but to also be sure that we added a note to the membership section that we encourage involvement from all parts of Fedora.

Term Lengths for Voting Members

nirik brought up the concern, “Currently we have it so turnover only happens if someone steps down from a voting seat. Do we want any term limits or other ways to keep a flow of fresh blood into the voting group?”

The discussion below is out-of-order, but grouped according to the threads of conversation, which were running concurrently for the most part.

Lifetime of the Server Working Group

Viking-Ice felt the Server Working group would dissolve once the PRD and process were put in place. He suggested indefinite terms and no elections, with the thought that the group would be short-lived. nirik believed that the group’s lifetime might be quite a bit longer, in saying “I think there will be ongoing work for this group for a long time…”

mitr added, “I’d almost say that the actual work _starts_ after the PRD, although the nature of it will change (coordination, prioritization of the “next service”, choosing software used to implement the PRD).”

“[W]hich product [gets chosen] or dropped is left up for the entire server community to decide (with the exception of the first three or so maybe to get the process nailed down,)” responded Viking-Ice.

mitr replied, “I don’t think people just following PRD can work. E.g. choosing between puppet/ansible/$many_other_alternatives needs to and up with a definite decision.”

“We are that decision making body?” nirik asked Viking-Ice.

“For the first products,” replied Viking-Ice. “[N]ot all products.”

nirik then said, “Well, for the products we decide that the Fedora Server group is going to ship, sure.”

Election Logistics

A conversation came up as to how we would hold a vote for new members if we were going to have terms.

“It is also not easy to organize an election,” pointed out tuanta. I pointed out that depending on the scope of the election (e.g., not the whole Fedora community but maybe just the server community, using the Fedora elections app or more informal in IRC or over the mailing list), it could be easier to organize.

mitr added, “I’m not tied to the Fedora election app, but (from the outside) it seems that it’s easier to use that app than to manually count votes, and the confidentiality is a significant benefit.”

nirik stated a preference to avoid the elections app.

Suggested Voting Terms

Evolution suggested a 6-month seat vote, but mitr wasn’t sure a 6-month term would work with an 18-month lifecycle.

mitr pointed out, “I’ll reiterate that I don’t think having indefinite terms is healthy, although this seems to be a minority opinion among the WGs.” However, both myself (mizmo) and nirik stepped up and agreed with him.

As mentioned earlier, Viking-Ice was in support of not having term lengths and instead having indefinite terms. “I personally dont see the need for the WG once the process is set,” as he stated his perspective on this. “No election[.] It would be better to simply have members confirm the continue[d] participation in the server WG every 3 or 6 months.”

I asked the group what specific concerns they had about Viking-Ice’s indefinite terms proposal. mitr responded, “The WG confirming itself is not an effective mechanism for replacing a dysfunctional WG. (I know we are all perfect and this is purely theoretical :) )”

After asking Viking-Ice if he had some way to account for that scenario, he replied, “Use the same approach as you propose we cross that bridge when we get there.” He also suggested that FESCo could be brought in to resolve issues in the case of dysfunction; when asked nirik said FESCo might be open to serving in that capacity.

I brought up my own specific concern about Viking-Ice’s proposal. “I’m worried about stagnation – usually the energy of new members coming on board regularly helps jump start people’s enthusiasm at the regular intervals of election. it doesn’t seem like this would be guaranteed in your proposal,” I said. “Do you have ideas on how to account for this in your proposal?”

“[L]ook at fesco same people for the last deca[d]e more or less,” he replied. “Fresh ideas killed instantly by the few fresh members that make it there so..”

In response, nirik then proposed another idea to help bring fresh members to the team, “Every 6 months we randomly choose 3 members to replace (would also need at least 3 more active folks in the group to replace them with.)”

This didn’t really go anywhere though, and nirik noted we had 10 days to submit a governance charter to FESCo.

nirik continued, “I’m not coming up with too many great ideas there… and it might depend on: a) how long we exist, b) how many non voting active people their are in 6 months, c) if we need more fresh voting members or if as Viking-Ice notes the active people in the community would be enough for that.”

“Actually… _if_ we are agreed that we should have some kind of turnover mechanism, then delaying might make sense; if we don’t have an enforced turnover, then let’s just close it now,” said mitr.

I responded, “I do think we need a turnover mechanism, but I agree with nirik that it’s kind of hard to know how to set that up without seeing how active the community membership is and how long we intend to exist.”

At this point, nirik proposed we vote on going with Viking-Ice’s proposal of indefinite terms and periodic (every 6 months) confirmation of working group membership. To interject some personal opinion here, it felt like consensus by exhaustion to me, and at least three people remarked while voting they were voting the way they were to ‘get this over with.’

What is quorum?

At the very end of the discussion mitr brought up the fact that the statement about quorum in the charter wasn’t technically correct with respect to the definition of quorum. It said we must have a quorum of 5 people to vote, which means the majority of 5 people (which is 3) positive votes would be required to agree to something in a vote. The intention behind the statement was to require 5 positive votes, regardless of how many people were present at the meeting, so the verbiage was updated to reflect that and all agreed to it.

Approved Governance Charter

So as of this meeting then, the Server working group has approved its governance charter as updated with the agreements and language discussed above:

Stephen Gallagher, our FESCo liaison, will bring the charter to FESCo for approval.

Is Fedora Server One Product?

We’d taken up an hour by the point we finalized the governance charter, but I think everybody present was able to continue on and the #fedora-meeting-1 room was empty still, so we went on for another hour.

The topic, “Is Fedora Server One Product?,” came from a thread of the same name on the server mailing list. The thread is relatively short:

  • Viking-Ice proposed that Fedora Server will be multiple products requiring multiple PRDs and also proposes a mission statement for the group. (The proposed mission statement: “Fedora Server WG where we discover product solutions that work well for
    our users, our administrators, our developers and our project.”
  • simo responded saying that Viking-Ice’s proposal “is not without merit” but says essentially it’s too large a scope and we’re not set up to do something like that. “It is not our core mission to go and modify single components,” he says. “I think our mission is more to interact with upstream and tell them what we think would greatly improve the situation for us and encourage them to provide those changes.” He also added, “I think what we want to do primarily though is build a foundation for
    all the interesting projects to run on. Provide the best possible, solid, core OS, people can depend on, where changes are pondered not only against the benefit they can bring to new admins but also how disruptive they would be to developers and existing admins. Our duty is to provide excellent transition tools for those times when disruptive change is necessary w/o having the ecosystem suffer for multiple releases.”
  • mitr responded to simo, agreeing completely with his last statement on the mission, but also pointing out that ‘upstream first’ doesn’t work well with the number of individual components we’d need to integrate.
  • mitr also responded to Viking-Ice, agreeing that ‘product solutions’ and end-user goals are the right focus, but he felt Viking-Ice’s emphasis on the application first wouldn’t work. He felt that having many individual recipes would be sub-optimal. “It doesn’t make much sense to me to make individual recipes starting with the application, and potentially diverging in the ‘infrastructure,’ he said. “Rather, the ‘infrastructure’ should be common and the base of the product, with the various services being treated more like ‘applications’ for the infrastructure (potentially some ‘bundled’ and some separate).”
  • sgallagh then reponsded to mitr’s response to Viking-Ice, saying that we could define many recipes in a reasonable manner depending on how we defined them. He gave examples of role-based potential recipes, basically suggesting that for each use case we have one ‘preferred’ technology / implementation. (Users could still install alternatives but there would be less support for it.

That was where the mailing list left off. The discussion in the meeting, though, was unfortunately a lot less efficient than the mailing list thread. I think we basically talked at each other saying the same exact thing using different terminology and getting confused over language. At one point I declared ‘product’ to be a dirty word and tried to come up with a different word to get around the blockage we kept running into. I will try to outline the path of the discussion so you can draw your own conclusions.

Well, is it one product? What is a product, anyway?

I started off by answering the question, “Yes, I think it’s one product.” When Viking-Ice asked me why, I had my ux-design and fedora-websites hats on, thinking about how 500+ ‘products’ would be represented on our web page. I made the point that, “If Fedora as a whole is to have three products [workstation, server, cloud], we’re kind of bursting at the limit of what potential end-users are going to be able to handle.”

nirik pointed out that we may be each thinking of something different for the meaning of the word “product.” He tried to ground the notion with a specific technical example: “Taking it from the deliverables angle, it sounded like people might like kickstarts + a netinstall iso… so we could produce N kickstarts for use with a netinstall… is each of those a ‘product’ ?”

“nirik, i wouldn’t consider those a product no,” I responded. “They are different configurations for the same product.”

Viking-Ice responded to nirik, “If it has gone through the transitioning process ( which I say is prd ) then yes.”

“So, it sure sounds like a terminology thing to me. ;)” concluded nirik.

“I think: just different meanings of what a product is,” tuanta added.

Unfortunately, the confusion didn’t end there. :(

sgallagh proposed, “To my mind, the Fedora Server as a product is a well-defined set of solutions that we have vetted for people to use. These solutions can be divided into ‘roles.'”

mitr said, “I think the common infrastructure (kernel, booting, basic libraries, choice of configuration/management/…) framework needs to be uniform for all deployments. There may be specific separate “single-click” ways to install a specific role (corporate LDAP / mail / Java application server, whatever), but those are all “roles” of a single product to me.”

In response to mitr, Viking-Ice stated, “I would call that common infrastructure between prd’s but I even doubt that it would be applicable to all of them.”

mitr responded, “When I said “needs” to be the same, I did mean “needs” – we will be manpower-constrained even for the new things that we need to do, reinventing the same functionality for different kinds of servers is a waste we can’t afford.” He continued, “I agree it’ll kind of strange if we announce Fedora Server 1.0 !!! Implements all of …. 2 TCP protocols! but the overall direction should be of a single product with multiple roles.”

“I mean, absolutely, each role needs to be defined,” I also responded to Viking-Ice, “but I think a PRD for each role is overkill.”

“Only one the base OS can be labeled a product,” said Viking-Ice.

nirik said that he “largely doesn’t care. call them ‘roles’ or ‘products’ does it matter in the end?”

“From my perspective,” sgallagh offered, “the duty of the Product would be to set the definition of how something gets promoted into a ‘supported’ role in that Product.”

mitr pointed out to Viking-Ice, “Or perhaps to take it from a different view, even if we have a nice pre-packaged LDAP and mail solution, I should be able to install a _single_ physical server that serves both, shouldn’t I?” If the pre-packaged LDAP solution was one ‘product,’ and the pre-packaged mail solution was another ‘product,’ the question here I think is whether or not you could combine two ‘products’ on one physical server.

mitr continued, “installation is an implementation detail at this level of discussion I’d say. I kind of like having a ‘single big installation medium,’ but a minimal netiso that allows installing the various roles would work just as well.”

“We need to be able to handle this on per product [basis] as in ldap as one product and a mail server as another,” Viking-Ice responded.

“Why?” asked mitr.

“[The] workstation working group has multiple and I suspect it’s going to blow over due to [its] gnome-ism and the DE community’s [way] with it,” Viking-Ice responded. “The cloud depends on our mutual definition of what is cloud and what is server and the [environment] and baseos [don’t] have 1 multiple apps so to speak. I see products as single or multiple server application which an roles could be applied upon.”

I asked, “What are other working groups calling what they are working on? Do they have roles vs. products issues?”

mitr responded, “I think the other groups don’t have the equivalent of an ‘1-click mail server’ use case.”

“There are some different desktops (Gnome, KDE, XFCE, etc.) in Workstation WG,” tuanta pointed out. “It is also equivalent, I think.”


At this point I tried to do a recap of the multiple concurrent threads:

  1. We seem to have confusion about products vs. roles.
  2. We all agree – whether or not they are ‘roles’ or ‘products’ – they will share kernel, booting, basic libraries, choice of configuration/management/etc.
    • Viking-Ice agreed with this.
  3. We’ll make technology choices about what is the single supported way to do something (e.g., mailserver) but won’t preclude users from installing alternatives, just with less support.
    • Viking-Ice took issue with this statement, “There is no such thing as support in Fedora and people should really stop saying that instead use ‘best effort.'”
    • I replied, “There is such a thing as support in terms of, what does the documentation recommend? what is the default assumed configuration? etc.”
    • “Might say ‘featured’ or something?” nirik suggested as an alternative to ‘supported.’
  4. Each server could have multiple roles at the same time (e.g., email and ldap server.)
    • nirik showed concern about this: “If we allow multi role, we are going to have quite a combitorial QA doom.”
    • mitr responded by saying, “I don’t think it’s really different from having two or more applications installed at the same time – as long as they don’t talk to each other.”
    • “Sure it would be…” nirik replied. “Unless we don’t test anything as much as we don’t test it now.” He also pointed out, “Also, we can’t easily do multi with kickstarts…”
    • I replied, “Well we could…. depending on how the roles are defined. Using comps groups for example.”
    • “[Comps] groups are a mess and need to be reworked from ground up,” said Viking-Ice.
    • “But dealing with this as an single application or applicaton stack per product will allow us to host test days with that or those combined products,” pointed out to nirik.
    • “Kickstarts are a modifiable concept :)” mitr said. “Anyway, I really proposed this as a way to tell the difference between a single server / multiple servers. I’m really unwilling to back down from being able to install a single machine that serves two roles simultaneously (without resolving to virt.)”

How many PRDs can a product chuck if a product can chuck PRDs? And what is a PRD?

After a lot of the above discussion, which occured in a more interleaved manner than represented above, sgallagh tried to call some order: “Can I take a step back here and try to center us on the question we’re trying to answer? Could we agree to work on separate chapters of the same PRD for now, with the option to split them up later if it becomes obviously necessary?”

nirik pointed out that he “thinks prd per application is overkill, but perhaps thats me.”

“Trying to apply a prd to the entire group is [nonsense,]” responded Viking-Ice.

I offered, “Let me tell you why I think PRD per application is overkill, and you let me know what you think – the PRD for each of those applications is the responsibility of upstream, not us. The upstream FreeIPA team, for example, is responsible for the FreeIPA PRD. We are only responsible for the PRD of the platform on which applications and stacks like that are meant to be deployed on.”

sgallagh said, “I don’t agree with that 100%. I think we should be able to modify those packages to fit with our goals.”

“I disagree with that,” said mitr, “modification and integration of upstreams should be in our scope as well.”

“Modification and integration is fine,” I repsonded, “but a full PRD for the application I think is out-of-scope.”

“I agree we will need a PRD for the individual app stacks, to make sure it’s integrated correctly and the like,” said mitr, “but they are all unified by the shared base, config management, monitoring and the like, and _that’s_ one basis of the server PRD; the other being a list of app stacks we want/need.”

nirik added, “I would want a fair bit of information for a ‘role’ or whatever we want to call them… before commiting to producing, testing and delivering it.”

nirik then made a proposal: “Make a single server PRD that includes what information we need from ‘roles’ and includes the initial set of them we intend to deliver.”

“-1 that’s not what prd’s are for,” responded Viking-Ice.

“Ok, then what are they for?” asked nirik.

Viking-Ice replied, “Defining the transition process from an marketing idea to a product.”

nirik said that he was, “confused, really the PRD is for fesco to tell them what we are making right?”

“The server community is not a product,” said Viking-Ice. “Fedora Server is not a product. ‘Fedora Freeipa Server’ is a product.”

“Ok, well, I guess I don’t care if we make a bunch of PRD’s instead of one,” replied nirik, “but I suspect a lot of it would overlap, no?”

Viking-Ice replied, “Yes, hence I said we needed to do 3 or more products so we could identify where they would overlap.”

“Fedora Server is a product in the same way that Microsoft Windows Server 2012 is a product,” sgallagh pointed out.

“I’m pretty sure the point of the PRD is to define the problems a product solves, and in this specific case to let FESCo know what specific problems we feel need to be solved in the server space,” I suggested.

sgallagh said, “I suspect that we maybe just chose the wrong term by calling this document a ‘PRD,'”

“How about ‘Fedora Server Feature Requirements List,'” I offered. “What would we call ‘Fedora Server’ if we were avoiding the word ‘product’?” I came up with “Fedora Server Platform.”

Continuing, I asked Viking-Ice, “Viking-Ice, are you okay with putting together a single functional requirements document for the Fedora Server Platform? That document can include all of the application stacks and roles of interest.”

“Single functional requirements document for the Fedora Server Platform is one thing but dont think we can apply the application stack or roles of interest to it ( yet ),” he replied.

nirik said, “I don’t care what we end up calling things. I want a common base thing (netinstall iso, whatever) and some ‘featured application stacks’ or whatever that we commit to putting together from our collection and making shine.”

“Nirik, i think we all agree, vocabulary hangups aside,” I responded.

Nirik proposed, “common base platform with ‘featured application stacks’ built on top of it. We commit to produce, test and distribute these application stacks,” to which he received multiple affirmative responses. He continued, “Thinking about it, we will need a way to promote/add new applications, so perhaps the requirements doc could just explain how that happens and the applications could be seperate. Whatever works tho.”

I think we kind of fell apart from there, though, and ran out of time. So I’m guessing next meeting we’ll try to pick this topic back up and come to some resolution.

Meetbot Minutes

Here is the official meetbot meeting minutes with links to the full raw log: