Meeting Summary / November 26, 2013

[Máirín Duffy]

Hi folks!

Below find a summary of yesterday's meeting. You can also read it in
blog format at
http://fedoraserver-wgblog.rhcloud.com/fedora-server-working-group-nov-26-meeting/
.

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


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

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

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

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