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, 9 months
Stuff that should be our target going forward ?
by Simo Sorce
Ok this is just an example that hit me today, so I wonder what is the
opinion here, please do not concentrate on the problem at hand but on
the general problem it highlights (user experience on server).
In a headless F20 if you "yum install firefox" you get a broken
application when you want to run it through an ssh session (I ssh -Y in
my VM).
I think this is a reasonably common mode of operation, and yet
installing firefox does not bring in all the dependencies it needs to
actually work.
The classic dependency it misses that I know about is xorg-x11-xauth,
however in F20 firefox apparently also misses fonts and will show an
unintelligible crash report dialog (unintelligible because there are no
fonts).
I think a good server experience will require that yum install firefox
on a headless system installs all required packages to make it work, is
this something we need to take care of going forward ?
Apparently there is some dispute about who owns the bug, but I wasn't
able to find out where, on #fedora-devel I was told it was in a bug that
has probably been closed w/o resolving the issue ...
Simo.
--
Simo Sorce * Red Hat, Inc * New York
9 years, 10 months
The "Membership" section of the governance charter draft
by Máirín Duffy
Hi folks,
One discussion we didn't get to finish in today's meeting was the
membership section of Jóhann's governance charter draft. As stated
during the meeting, he felt having this cross-section of Fedora would
"ensure coverage and proper release process for server product."
The draft link is here, for convenience:
https://fedoraproject.org/wiki/User:Johannbg/ServerWG
After the meeting I went back to the Fedora.next proposal to see what it
says about membership in the working groups and read this:
"There will be at least one FESCo member in each to act as a liaison.
There should be a liaison with the QA, rel eng, docs, marketing, and
web/infrastructure groups as well although these may not be people from
those teams but people tasked with facilitating dialogue between those
groups and the working group instead."
Jóhann's proposal seems to follow the spirit of this (adding the design
team as a group needing representation; thank you for that. :) ) With
that in mind I've changed my position on this matter a bit, and I would
like to hear your thoughts on this proposal:
- The proposal says we would continue to have nine voting members, but
then talks about there being a member each to represent 7 Fedora groups
and 3 additional members to represent the server community itself. I
think the representation of the server community itself is too slim
here, and I think the slots could overlap.
- I would like to propose instead that we maintain a nine voting member
roster, but require that at least five of the members be able to
directly represent the server community. By this, I specifically would
like to require any or all of the following requirements be met by a
'server community' representative (under which all of our current
'server community' reps and other members qualify as well):
- member has worked professionally as a system administrator for a
deployment of at least 10 production servers
- member has been involved significantly as a contributor to an
enterprise Linux distribution or enterprise management product for Linux
servers.
- Instead of having each of the cross-section teams across Fedora (docs,
rel-eng, QA, ambassadors, infra, design, marketing) have a member of
their team directly serving in the Server working group, I would like to
suggest instead following the Fedora.next proposal suggestion that each
of these teams have a liaison on the working group who isn't necessarily
a member of the team they represent. So, for example, Stephen could be
the liaison for the Fedora marketing team even though he is not a member
of that team, and whenever the working group needs to interface with
that team it would be Stephen's responsibility to contact them. So each
team has a 'go-to' person on our working group, and our working group
has a 'go-to' person for each team we'd need to interface with. To have
the same person managing the relationship could simplify communications.
- In order to determine who is the liaison for which of the 7 groups,
for now we could go with people who are a member of the groups are the
liaison and groups that do not have a member on the working group would
have a member not already a liaison for another team nominated to be
their liasion. When someone who is the liaison for a given Fedora team
leaves the group, that group will be given the opportunity to suggest a
replacement but the decision as to who to pick would ultimately be up to
the remaining members of the working group.
With this proposal in mind -
I am still not sure how the turnover works. Do we serve until we're sick
of serving, or is there a term / period we are on and then are up for
re-elections? The draft does not cover this really.
Anyway, let's discuss :)
~m
9 years, 11 months
Fedora Server Personas / Target Users
by Máirín Duffy
Hi,
I think having a set of target users or personas defined for the Fedora
Server product will help inform our decisions about the product and are
critical for its success. [1] I think at some point we should put a
discussion about personas on the meeting agenda.
To this end, I started a (quite bare) 'Personas' document on the wiki
based on previous discussion here on-list:
https://fedoraproject.org/wiki/Server/Personas
Let me just write a little bit about where personas should come from
(not necessarily where they come from in the resource-constrained real
world):
- Interviews with potential users, whether informal or done contextual
inquiry style
- Surveys
- Market research data
- Literature reviews (basically reading through others' research)
>From reading the discussion so far, it seems that we might be trying to
reach users who aren't current Fedora or even Linux users. We should
develop personas for these reach users, too.
All of the users, I think, are sysadmins. Maybe some developers? Things
to think about for each persona:
- What is their job role?
- What level have they attained? Are they a student, intern, junior,
senior, executive, etc.
- What kind of environment do they work in? E.g., academic?
High-pressure in-house IT department for a financial company? Are they a
consultant? Hobbyist?
- What is their technical level? RHCT / RHCE / RHCA for example (This is
just one example of how to measure this)
- Demographics - how old is someone in this position, typically?
- Referrals - how does this person find out about new technology? What /
who tips them off to try new things?
- Goals (most important) - what are they trying to do? For example, is
it a student trying to set up a web server to get a good grade on an
extra credit project? Is it a sysadmin team lead trying to minimize
outages and late-night phone calls?
- Computing platforms - what specific computing platforms do they care
about? Do any specific vendors stand out as being particularly important
to this user?
- What technology is most important for this user?
I think we probably would end up with maybe 4-5 personas (and maybe a
few other 'anti' personas - folks we are specifically not catering to
with this product) and we can refer to them in discussions moving
forward. E.g., we can talk about, for a given suggested feature, which
personas would benefits and which wouldn't, for example.
We could pitch different specific personas and drill through the above
suggested attributes to try to nail them down, or even drill through the
attributes first and see what kinds of personas shake out of that.
I hope this makes sense. What do you think?
~m
[1]
https://lists.fedoraproject.org/pipermail/server/2013-October/000285.html
9 years, 11 months
Re: Discussion of Fedora Server use-cases
by Máirín Duffy
On 12/31/1969 07:00 PM, Stephen Gall wrote:
> == What are our use-cases? ==
I wasn't subscribed to the list when this post originally went out so my
apologies if this attempt to reply to it messes up your mail client
threading -
I spent a few hours today combing through this use case thread and
started a use cases document in our wiki:
https://fedoraproject.org/wiki/Server/Use_Cases
It includes both proposed use cases from this list as well as various
discussion points that came up thus far.
~m
9 years, 11 months
Server WG and the Fedora project wiki
by Máirín Duffy
Hi folks,
I apologize in advance for my ignorance regarding the Server SIG -
We have a wiki page for the Server here:
http://fedoraproject.org/wiki/SIGs/Server
Is this content in active use? It appears to be focus on a server spin,
but I can't find a server spin on alt.fpo or spins.fpo. This mailing
list was also used by the server SIG - based on mailman archives, it
stopped being active in Nov 2010. [1]
Should we:
1) Clean-slate the page and re-purpose it for the working group and any
SIG members that are remaining?
or
2) Leave it alone and start a new one? (/wiki/Server or /wiki/ServerWG?)
I'm particularly interested in hearing from original Server SIG folks!
~m
[1] https://lists.fedoraproject.org/pipermail/server/ There's a
year-long gap where there are some posts in late 2011/early 2012, then
an almost 2-year long gap between February 2012 and now.
9 years, 11 months
Meeting Summary / October 30, 2013
by Máirín Duffy
Hi folks!
Below find a summary of today's meeting. You can also read it in blog
format at
http://blog.linuxgrrl.com/2013/10/30/fedora-server-working-group-initial-...
. Below the summary, you'll find the meetbot links if you'd like to read
the raw logs.
Meeting Minutes
===============
Here’s a run-down of today’s Server Working Group meeting:
Agenda
======
* Meeting frequency and times
* Ticket Tracker/Wiki
* Governance Charter
* Open Floor
Meeting Frequency and Times
---------------------------
First we talked about how frequently we should meet and at what time.
This diverged a bit into other topics (how to handle absences and time
zone issues.) We agreed on the following points:
* The Server working group will meet on a weekly basis. There wasn’t any
dissension about or discussion on this point.
* If there is no agenda posted to the mailing list within 24 hours
before a meeting is set to start, the meeting is cancelled and Stephen
will send out a cancellation notice to the mailing list. Jóhann
suggested the cancellation note just so that it’s clear the meeting is
not happening.
* Stephen will send out an email to the voting members to figure out a
time that works for everyone on a weekly basis. It was pointed out that
the United States is going to go through another time shift this coming
weekend, and we’re coming down off a flurry of conference travel with
folks travelling across timezones, so we need to set a time that will be
sustainable long-term.
* In the case where a voting member can not make a meeting, they can
either pre-vote via the mailing list or abstain-by-default. I did raise
a concern about unplanned votes taking place due to a disagreement that
cropped up during a meeting that an absent member could not forsee to
pre-vote on, but we decided keeping things simpler is best, and if that
one vote wouldn’t have mattered anyway it is not a big deal. We’ll wait
until we run into a situation where the absence becomes a problem to
make any policy for it.
* During meetings, silence indicates consent. If people disgaree, then
that will bring it to a vote. As Kevin pointed out, “I think we should
strive to work on consensus, and only vote on things where it’s clear
people aren’t going to be convinced to agree.”
Ticket Tracker/Wiki
-------------------
We then moved on to talk about the tools we will use to conduct business
– managing and tracking our progress. Some of the asset types that came
up as needing to be managed with tools were:
* Working documents (governance doc, PRD)
* Agenda items
* Decisions
* Discussions
* Meeting minutes / summaries
While Stephen suggested initially that we set up a Trac instance to keep
track of agenda items and discussions, several members (Jóhann, David,
Simo) had concerns about prematurely setting up Trac before we had
determined through experience that we needed it. We collectively decided
to table any Trac set up and to use the Fedora wiki to trac agenda
items, decisions, and discussions until it became too unwieldy. At that
point, we would have the experience to fully understand the requirements
of the tool we needed and be able to select a tool based on
requirements. Again, the overarching concern here, I believe, was
simplicity.
I volunteered to start a blog for the group to share meeting minutes and
any progress we’ve made (so here you are. :) ) Initially I’m going to
make the blog posts here on my personal blog, but I will also set up a
group blog for the Server working group on OpenShift and have that
subscribed to Planet Fedora. Meeting minutes will also be posted to the
server mailing list as well as to the Fedora meeting minutes list.
It was very unanimously agreed that the working documents would be
stored on the Fedora project wiki, following the lead of the Cloud
working group.
Governance Charter
------------------
We then moved on to start discussing the governance charter. Jóhann very
helpfully put together a Fedora Server working group governance charter
draft which we read through and used to direct the discussion.
Jóhann’s draft has four main sections:
* Membership
* Current Members
* Making Decisions
* Changing These Rules
While there was a lot of agreement about the content of the other three
sections, there were some concerns and disagreement about the content of
the membership section – enough that the discussion was not conclusive
and we decided that we should discuss it further on the mailing list and
it should be part of the agenda for next week’s meeting.
The main point of contention about the membership section was that there
are certain slots in Jóhann’s proposal meant to be dedicated to specific
teams within Fedora. There were several concerns voiced about this
team-based slot approach:
* Some teams in Fedora are spread thinly enough that they might not have
anyone willing to serve in representation of them. The counter to this
concern that Kevin proposed is that the groups would be given ‘first
dibs’ at nominating someone to fill their slot, and if they couldn’t
then the slot would open up to anybody interested.
* It’s not really clear what advantage having someone from each team
would provide the group – it was pointed out by both mitr and mclasen
that it is easy to reach out to folks on other teams and get help from
them, and being a direct member of the working group isn’t necessary to
assit the group.
* Some of the slots are reserved for people who represent the ‘server
community,’ but it isn’t clear how someone would be identified as
representing the server community or not. What exactly is the server
community? Doesn’t everyone on the working group need to represent the
server community? How can you discern if someone is qualified to do that?
* Miloslav was concerned about this resulting in the group “having a
great planning infrastructure and no one to do the planned work,” and
suggested it would be better if the group was made up primarily of
‘do-ers’ who can get things done rather than decision-makers who would
need to rely on external volunteers to get the work done.
Hopefully we’ll have some discussion about these points and others and
clear up what we think the membership section needs to say.
Open Floor
----------
We only had about 5 minutes left (and went over by 5 more) after
determining the main meat of the governance proposal that we had to work
on was the membership section. We threw out different ideas for loose
threads of discussion and other issues we thought should be considered
for the next meeting’s agenda:
* The governance “membership” section – The ‘membership’ section of the
Server working group governance draft.
* The use cases for the Server product – discussion of this is already
happening on the mailing list. These should help inform the product
requirements document the team needs to put together for January.
* Short-term deliverables and PRD – Kevin suggested that we should start
discussions on the team’s short term deliverables and initial PRD work.
* General direction of how the product will be made – Simo brought up
that we might need to discuss ‘how the sausage gets made,’ e.g., “are we
going to suddenly have 4 different rawhides or how to we handle package
management.” Jim responded with, “I would hope we’re still working from
a common package set, and either putting our changes in the packages or
groups.” Simo concluded that, “I’d like we discuss a bit in the agenda
what we think is the general direction and the ‘absolutely not’ and the
‘absolutely can’t do without.’”
* Mission statement – Stephen suggested, to follow the Workstation
group’s lead, that we put together a mission statement (and potentially
a vision statement.) I’m going to draft the initial statements and send
them to the list for discussion.
Meetbot Minutes
---------------
Here is the official meetbot meeting minutes with links to the full raw log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedoraserver...
Full set of meetbot links:
Meeting ended Wed Oct 30 18:05:15 2013 UTC.
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedoraserver...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedoraserver...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedoraserver...
9 years, 11 months
Server product kernel requirements
by Josh Boyer
[ Resend with the right server mailing list address. Sorry kernel@ people.]
Hi All,
I realize the WG is just forming up and you have a lot of other items
to cover for now, but I wanted to get this sent out and have people
start thinking about it sooner rather than later.
The kernel team is interested in what the Server WG sees as its
requirements for the kernel package. Does today's kernel image mostly
suit those needs already, or are there changes that would be
beneficial?
While you think about this, please keep in mind that the kernel team
really wants to keep a single kernel package across all 3 products as
much as possible. We won't scale to providing multiple kernel
packages or vmlinux binaries for each product. At the moment, we're
essentially looking for a good "core" kernel package that suits cloud,
server, and workstation and then at repackaging the drivers into
subpackages where appropriate.
If you have changes you'd like to see, please let us know what they
are and the reasoning behind those changes. Hopefully we can work
with all 3 WGs and come up with something suitable for everyone.
Thanks for your time.
josh
9 years, 11 months
Discussion of Server Working Group governance
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The first goal of the Working Group process is to plan our governance
process for future members of the Server Working Group. I think the
place we should start is by gathering a list of requirements that a
governance charter will need to keep in mind. I'll list my thoughts
below, please raise your own concerns as well.
In no particular order (stream of consciousness):
== Voting Members ==
* Number of voting members for the Working Group.
* How long a term do the voting members serve?
* Should there be term limits or mandatory breaks?
* Should there be reserved chairs for specific constituencies (e.g.
QA, Ambassadors, Release Engineering)?
* Voting method?[1]
* Who can vote?[2]
* Recalls?
== Charter ==
* How do we approve the initial charter?[3]
* How do we later amend the charter?[4]
== My initial thoughts ==
I am open to counter-arguments, naturally.
[1] For simplicity, I suspect we want to stick with range-voting as in
the other elections. We already have the tools for this.
[2] I recommend we stick with FPCA+1 as a rule for voting.
[3] For the initial charter, I think if it's not unanimous, we need to
keep talking.
[4] I think amendments should require "voting members - 1". It
shouldn't be possible for a single dissenting vote to hold things up
(they should get to have their say), but otherwise I think that a
near-unanimous vote should be required to change the fundamental
guiding document.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJuXs8ACgkQeiVVYja6o6N2tgCfXEppjzE74YuORa+B7jAjBFGZ
0oMAn1h9GP+GVjJ4qYiVUVZ6K7gol5Sk
=cFLM
-----END PGP SIGNATURE-----
9 years, 11 months
Server Working Group Public IRC Meeting
by Stephen Gallagher
The following is a new meeting request:
Subject: Server Working Group Public IRC Meeting
Organizer: "Stephen Gallagher" <sgallagh(a)redhat.com>
Location: #fedora-meeting-1 on Freenode
Time: Wednesday, October 30, 2013, 1:00:00 PM - 2:00:00 PM GMT -05:00 US/Canada Eastern
Invitees: server(a)lists.fedoraproject.org
*~*~*~*~*~*~*~*~*~*
We will have our first Server Working Group public meeting on Wednesday, Oct 30th in #fedora-meeting-1 on Freenode.
== Agenda ==
* Meeting frequency and times
* Ticket Tracker/Wiki
* Governance Charter
9 years, 11 months