Discussion of Fedora Server use-cases
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
== What are our use-cases? ==
Full disclosure: the use-cases I am listing below come from
discussions I have had within Red Hat for what we would like to see in
Fedora that we can best build on to become Red Hat Enterprise Linux 8.
Please take this in the spirit it is given: I am disclosing what Red
Hat wants up front, so we aren't accused of working towards hidden
goals. I am also not committing us to covering any or all of these
targets. I do believe however that the majority of these use-cases
will be beneficial to both Fedora and Red Hat.
* Provide a platform for acting as a node in an OpenStack rack.
* Provide a platform and simple setup for certain infrastructure
services, e.g.
* FreeIPA Domain Controller
* BIND DNS
* DHCP
* Database server (both free and commercial).
* Provide simple setup of a file-server (on par with Windows).
* Platform for deploying web applications with high-value frameworks.
* Ruby on Rails
* Django
* Turbogears
* Node.js
* Make Fedora the best platform to deploy JBoss applications.
* Come up with standardized mechanisms for centralized monitoring
* Come up with standardized mechanisms for centralized configuration
and management
* Simple enrollment into FreeIPA and Active Directory domains
* Provide the best platform for secure application deployment
* Isolation of OS from applications
* Isolation of applications from each other
* Isolation of application users from each other
* Management of application resource consumption
* Simplify management and deployment.[1]
* Deliver the world's best leading edge DevOps platform.
== My initial thoughts ==
I am open to counter-arguments, naturally.
[1] Ideally, we want a mid-level Microsoft admin to be able to manage
Fedora without much learning curve.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJuXtgACgkQeiVVYja6o6P/lACeONPUpvTIPM0aLcWMAOYJMltr
OjkAoJx/Kdm8wKUVCgkmr48hIE6B7ud6
=2QFz
-----END PGP SIGNATURE-----
9 years, 11 months
Making migrations common (and not scary)
by David Timothy Strauss
(Pulled out of the meeting thread)
We've been talking about extended lifecycles as an admin-friendly
direction to take Fedora Server. But, I think we should consider
spending more resources better-supporting migrations to new servers,
including OS version bumps. Administrators often favor long lifecycles
because this process is usually tedious and error-prone. The more we
make this part of normal operations, the more we make super-long
lifecycles unnecessary.
It's probably ambitious for a first release, but it would be amazing
to have good tools for vacuuming over services, containers, and VMs.
The latter two already have tooling, but it would be super cool to
abstract it into a general utility for migrations. It could enumerate
migration-enabled resources. Integration with RPM verification could
list configuration that's not possible to automatically migrate.
10 years
Meeting Summary / November 26, 2013
by 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...
.
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-meeti...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeti...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeti...
10 years
Agenda for Server Working Group Meeting (2013-11-26)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I sent out a request for agenda items on Friday. Based on the feedback
I received, I think our agenda looks like this:
* Select a new member of the Working Group[1]
* Discussion of Personas
We may want to discuss the lifecycle and updates topics in relation to
the recent FESCo ruling[2]].
[1] It was suggested in the mailing list thread that we should contact
the other volunteers from
https://fedoraproject.org/wiki/Fedora.next/WG_Nominations#Fedora_Server_W....
I have not had a chance to do this, but it might be equally prudent to
send out a general call for new volunteers. We can discuss this at the
meeting.
[2] https://fedorahosted.org/fesco/ticket/1202#comment:12
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKT+doACgkQeiVVYja6o6OJxQCeJURa4g0PXM2uMqmH5FJwYK5/
3PMAnRFWgNsZ5DOWssDr7g3aDySxS9Ra
=F1UL
-----END PGP SIGNATURE-----
10 years
Call for Agenda (2013-11-26)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Let's try to set an agenda for this week's Server WG meeting. Please
respond to this thread and I'll send out the formal agenda on Monday.
Last week, we had two topics that were deferred, pending input from FESCo:
* Server Lifecycle Proposal (sgallagh)
* Updates and Testing Proposal (nirik)
Additionally, I regret to report that Jóhann B. Guðmundsson has chosen
to vacate his voting seat on the Server Working Group. Pursuant to our
governance charter[1], it is now incumbent upon the remaining working
group members to elect a new peer. We are, therefore, now soliciting
volunteers.
* Select a new member of the Working Group.
[1] https://fedoraproject.org/wiki/Server/Governance_Charter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKPg1kACgkQeiVVYja6o6ObowCfcJGngW9xnumiiySlBKtXfp5v
PogAnjEd3HklIUvlytF95jYv0PhdOTJn
=5su7
-----END PGP SIGNATURE-----
10 years
Persona template & some initial rough cuts
by Máirín Duffy
Hey folks,
At the last meeting I took the action item to come up with a persona
template and maybe even take a stab at some rough cut personas.
I put together this based on nirik's persona suggestions from the
meeting. We may have other personas we need. Most of the info for each
persona is complete filler and stuff I made up. I look to you folks as
the experts who will be able to help fill in the blanks or point me to
folks who'd be good to talk to / representative for each persona to
figure out the various bits.
Anyway, take a look, tell me what you think? Do these make you think of
another case we may have forgotten? Think about environments, experience
level, organization type, type of deployment, that sort of thing.
https://fedoraproject.org/wiki/Server/Personas
~m
10 years
Fedora Server Blog and Proposals
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
First of all, if anyone is not already aware, the Fedora Server
Working Group is maintaining a blog on our ongoing efforts to plan and
execute a Fedora Server product[1].
To date, this blog has been primarily limited to Máirín's excellent
novelizations^W summaries of our Working Group meetings. I'd like to
extend this a bit so we can achieve some greater exposure on the
topics we are discussing.
For example, we have several threads on particular proposals, such as
the "Thoughts on Fedora Server Lifecycle" and "updates and testing
instead of lifecycle". I think it would be highly valuable for us to
write up blog entries on each of these topics and publish them.
Because this blog is aggregated on planet.fedoraproject.org (and
possibly on other aggregators as well), we should be able to keep a
much wider set of potential users and contributors informed of our
progress.
I'll be putting up a write-up of my lifecycle proposal (probably
largely stolen from Máirín's summary page[2]. I encourage Kevin to do
the same for the updates and testing proposal and Jóhann to do so with
his FOS/FOSSP proposals as well. If either of you don't have an
editor/publisher account on the blog, create an account with your
Fedora FAS OpenID and ask Máirín or I to give you access.
[1] https://fedoraserver-wgblog.rhcloud.com
[2] https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKOa3QACgkQeiVVYja6o6OCRgCeN2RyySNU8wwiwHPADhZpLPIw
1nAAnReWrnjxEYhnahoeywvHzG1twALs
=pwD5
-----END PGP SIGNATURE-----
10 years
Meeting Summary / November 19, 2013
by 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/?p=32 .
Below the summary, you'll find the meetbot links if you'd like to read
the raw logs.
If there are any mistakes in the summary here please edit as appropriate
on the wordpress blog: http://fedoraserver-wgblog.rhcloud.com/wp-admin
~m
Meeting Minutes
===============
Agenda
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.
Personas
--------
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 longerm 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.
https://fedoraproject.org/wiki/User:Johannbg/FOSSP#Server_Role_Process_Ag...
“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:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-19/fedora-meeti...
10 years
PRDs
by Máirín Duffy
Hi,
I read this in Stephen's summary from the FOSSP thread and I wanted to
discuss it:
> == Role Process ==
> Jóhann does not like the term PRD and feels that the term as
> defined[4] doesn't really make sense for a community project.
> Moreover, he feels it doesn't make sense when applied to the role
> projects. He envisions that each role we harden and tie into our
> deployment API should be developed as a project of its own, following
> a different (non-PRD-driven) process. He suggested that Stage-Gate[5]
> might be a useful approach for this.
Why doesn't a PRD make sense for a community project? Why, specifically
is having a PRD at odds with the product having various roles?
Stage-Gate doesn't appear to be a substitute for creating a PRD... it
looks like a standard software development process, to be honest. And
you could say we're following it right now - Stage 0 / Discovery was the
Fedora.next proposal and iterations, Stage 1 / Scoping is the ongoing
working group discussions... But please correct me if I'm wrong - I
never heard of Stage-Gate before.
The main alternative to using PRDs that I'm aware of is the agile model,
which I don't think we're following. But even in agile you have to put
requirements together in the form of user stories [1]...
That being said: isn't it a "Pandora's Box" to start geeking out on
software development methodologies? Is this really the best use of our
time? We need requirements, no matter what.
Please, can we just come up with a requirements document?
~m
[1] http://www.agilemodeling.com/artifacts/userStory.htm
10 years