server October 2013

server@lists.fedoraproject.org

20 participants
12 discussions

Discussion of Fedora Server use-cases
by Stephen Gallagher 19 Dec '13

19 Dec '13

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

13 72

Stuff that should be our target going forward ?
by Simo Sorce 04 Nov '13

04 Nov '13

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

6 15

The "Membership" section of the governance charter draft
by Máirín Duffy 01 Nov '13

01 Nov '13

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

6 16

Fedora Server Personas / Target Users
by Máirín Duffy 31 Oct '13

31 Oct '13

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

1 0

Re: Discussion of Fedora Server use-cases
by Máirín Duffy 31 Oct '13

31 Oct '13

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

1 0

Server WG and the Fedora project wiki
by Máirín Duffy 31 Oct '13

31 Oct '13

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.

4 5

Meeting Summary / October 30, 2013
by Máirín Duffy 30 Oct '13

30 Oct '13

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-me… . 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/fedoraserverwg… 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/fedoraserverwg… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedoraserverwg… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedoraserverwg…

2 1

Server product kernel requirements
by Josh Boyer 30 Oct '13

30 Oct '13

[ 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

6 9

Discussion of Server Working Group governance
by Stephen Gallagher 29 Oct '13

29 Oct '13

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

5 6

Server Working Group Public IRC Meeting
by Stephen Gallagher 29 Oct '13

29 Oct '13

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server October 2013