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:
IRC Channel: #fedora-server on Freenode IRC
Mailing List: server at lists.fedoraproject.org
Wiki Page: https://fedoraproject.org/wiki/Server
Meeting Minutes
Agenda
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.
Personas
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: https://fedoraproject.org/wiki/Server/Personas. 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:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeting-1.2013-11-26-16.00.html