Fedora Server Working Group: Nov 5 Meeting

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:

• IRC Channel: #fedora-server on Freenode IRC
• Mailing List: server at lists.fedoraproject.org
• Wiki Page: https://fedoraproject.org/wiki/Server

Meeting Minutes

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

Agenda

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:

• http://fedoraproject.org/wiki/Server/Governance_Charter

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.”

Recap

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:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting-1.2013-11-05-16.02.html