server November 2013

server@lists.fedoraproject.org

28 participants
36 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

Making migrations common (and not scary)
by David Timothy Strauss 03 Dec '13

03 Dec '13

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

3 4

Meeting Summary / November 26, 2013
by Máirín Duffy 27 Nov '13

27 Nov '13

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-m… . 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… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-26/fedora-meeting…

1 0

Agenda for Server Working Group Meeting (2013-11-26)
by Stephen Gallagher 26 Nov '13

26 Nov '13

-----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_Wor…. 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-----

1 0

Call for Agenda (2013-11-26)
by Stephen Gallagher 26 Nov '13

26 Nov '13

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

4 7

Persona template & some initial rough cuts
by Máirín Duffy 22 Nov '13

22 Nov '13

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

3 6

Fedora Server Blog and Proposals
by Stephen Gallagher 21 Nov '13

21 Nov '13

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

1 0

FedoraOS Server Platform ( FOSSP )
by Jóhann B. Guðmundsson 20 Nov '13

20 Nov '13

Few notes about FedoraOS Server Platform ( FOSSP ) Which touches serveral topics we have been discussing. JBG 1. https://fedoraproject.org/wiki/User:Johannbg/FOSSP

6 44

Meeting Summary / November 19, 2013
by Máirín Duffy 19 Nov '13

19 Nov '13

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_Agre… “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-meeting…

1 0

PRDs
by Máirín Duffy 19 Nov '13

19 Nov '13

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

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server November 2013