server November 2013

server@lists.fedoraproject.org

28 participants
36 discussions

Regrets not to attend today meeting
by Truong Anh Tuan 19 Nov '13

19 Nov '13

Hi everyone, I will have a trip tommorow morning so I can not attend today meeting. I will read the logs. Kind regards, Tuan

1 0

Installation Roles vs. Post-installation Role Assignment (or pets vs. livestock)
by Stephen Gallagher 18 Nov '13

18 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One topic that keeps coming up on other threads that I think we need to address first is when and where roles are assigned and whether they can be modified after installation. There are two general trains of thought here (maybe more; please chime in if you see other approaches). First, for those of you who haven't heard the "pets vs. livestock" metaphor, it goes something like this: Traditional datacenters are like pets. You have a few beefy machines dedicated to one or more tasks each. You maintain them, care for them and nurse them back to health if they get into trouble, much the same way that a pet owner would take care of their dog, cat, ferret, etc. On the other side of the fence, you have the DevOps/Rapid Deployment/Rapid Recovery folks who treat their environments more like cattle. They have lots of redundant, scale-out VMs that serve a single purpose and if they begin to have issues (memory pressure, intrusion, chaos theory progression), they are cut down and replaced with a new, pristine copy. This is analogous to livestock, where if one cow stops producing milk, it's usually served as hamburgers shortly thereafter and the farmer goes and buys another cow. So I think we need to take a look at which of these two approaches we want to be addressing. Or if we intend to try to handle both. It's my understanding that the Fedora Cloud Working Group is *very* heavily focused on addressing the "livestock" side of this argument, so we may want to keep that in mind (and I've CCed Matthew Miller to represent that group in this discussion). If we choose to address the "pets" scenario (aka the traditional infrastructure scenario), we probably need to be looking at role assignment as an API (as suggested by Miloslav). Essentially, we should build an interface into the system that allows us to configure a role on demand - providing it the necessary configuration information - and have it produce a system that corresponds to our vision of an integrated solution. This API should be invokable either at Kickstart time or remotely via a console such as Cockpit or Satellite after installation and should have the same exact effect in either case. However, if we're looking more at addressing the "livestock" scenario, then we probably DO only care about the initial deployment being correct, which may be done via Kickstart or simply having a set of pre-generated VM/Container images that can be booted with an API to assign the configuration the first time it comes up. These are *very* different deployment strategies, and we need to determine which that we as the Fedora Server want to be pursuing before we go any further, in my opinion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKGIxIACgkQeiVVYja6o6MFjgCfTrcFEQJXyZwwLeaiayiTEgPx h9gAn18zpkv7gUOAJgTCY0XbVF/PllnH =pv+C -----END PGP SIGNATURE-----

5 15

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

18 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I sent out a call for agenda items on Friday, so here is the planned agenda for tomorrow's meeting at 1600 UTC in #fedora-meeting-1 * Goals for Server Role Installation (group) * Personas (mizmo) * Server Lifecycle Proposal (sgallagh) * Updates and Testing Proposal (nirik) * Server Role List Proposal (Viking-Ice) * Installation Roles vs. Post-installation Role Assignment (sgallagh) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKKOVQACgkQeiVVYja6o6MrTgCePJ6BajciaCGOH/00aLWTUQY6 rVYAoIij7HXW+zru3ane17cYVzO1OlD7 =A9GA -----END PGP SIGNATURE-----

1 0

Fedora.next Product Branding
by Ryan Lerch 17 Nov '13

17 Nov '13

With the creation of 3 products for Fedora, the Fedora Design Team anticipates many new questions around Fedora's brand. As the main caretakers of the Fedora brand, we are going to have to figure these things out within the next few months. For example, the Design Team is starting to think about how to answer these types of questions: • Should each product have its own logo? or • Can you add our product to the Fedora website? or • Can you make our product its own website? (How should we represent these products on the website? Should we allow products to have their own separate websites?) To start off the rebranding discussion, the Fedora Design Teamhas4 basic questions for each of the 3 product-focused working groups to answer: (1) What problem does your product solve, in one sentence? (2) Who is the target audience for your product, in one sentence? (3) List at least 5 products that successfully target the same target audience you are after. (4) List at least 5 products that try to solve the same problem. We are reaching out to each group individually to ask that you discuss these questions and come back to us with answers by Wednesday, December 4th2013. cheers, ryanlerch ------------------------- Fedora Design Team

3 5

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

15 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. Agenda items suggested from last week's IRC meeting: * Goals for Server Role Installation (group) * Personas (mizmo) * Server Lifecycle Proposal (sgallagh) * Updates and Testing Proposal (nirik) * Server Role List Proposal (Viking-Ice) I'd also like to add the discussion from the "Installation Roles vs. Post-installation Role Assignment" I started today as a stretch agenda item, if we have time and enough people have had a chance to weigh in on the mailing list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKGS2EACgkQeiVVYja6o6PRCgCePWwyC19ETLnQOv9D/GXUCdbm FqkAoJRxcBU9v167hKe/Sm9xfMoQq+MB =XzBl -----END PGP SIGNATURE-----

2 1

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

15 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. Agenda items suggested from last week's IRC meeting: * Goals for Server Role Installation (group) * Personas (mizmo) * Server Lifecycle Proposal (sgallagh) * Updates and Testing Proposal (nirik) * Server Role List Proposal (Viking-Ice) I'd also like to add the discussion from the "Installation Roles vs. Post-installation Role Assignment" I started today as a stretch agenda item, if we have time and enough people have had a chance to weigh in on the mailing list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKGS2EACgkQeiVVYja6o6PRCgCeMndmgix7lhQEBlg6VSsLlcsl AWMAn0OqOsD4MB90JTzPbKNDMg00m5oO =7S/0 -----END PGP SIGNATURE-----

1 0

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

15 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. Agenda items suggested from last week's IRC meeting: * Goals for Server Role Installation (group) * Personas (mizmo) * Server Lifecycle Proposal (sgallagh) * Updates and Testing Proposal (nirik) * Server Role List Proposal (Viking-Ice) I'd also like to add the discussion from the "Installation Roles vs. Post-installation Role Assignment" I started today as a stretch agenda item, if we have time and enough people have had a chance to weigh in on the mailing list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKGS2QACgkQeiVVYja6o6PvwQCgqMHpirXKUtLdap+ilsShohfG 9wUAn0QbSu/Z5xst6BEnkvk1qkC6TMCE =OBfJ -----END PGP SIGNATURE-----

1 0

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

13 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=16 . 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 ====== * Can a single server have multiple roles? * Installation of base + roles Can a single server have multiple roles? ======================================== This topic discussion covered the following points: * We agreed that a single server should be able to serve multiple roles. * Testing combinations of roles on the same server will be tricky. There are some known combinations that will not work (for example, FreeIPA isn’t compatible with mod_nss.) * We’ll start with basic, single server roles, and over time we will adde tested combinations. (All agreed.) “A server having multiple roles could be as simple as “In my cost-constrained office, I want my domain controller to also be my email server,” said sgallagh. I pointed out there were some concerns about that approach last week. sgallagh responded, “There was concern about being able to test such things.” “Yeah, testing can be a big pain if we have 10 featured things and you can install any one or any combo of them,” said nirik. “But we could also just say ‘we test each of these things alone, let us know if they interact poorly.’” mitr asked sgallagh, “We aren’t ordinarily concerned about testing a system that has both Firefox and Devhelp installed; isn’t this the same thing?” “At first glance I agree with you,” replied sgallagh. “but with server applications they can sometimes interact with each other in odd ways. Such as requiring mod_nss vs. mod_ssl in apache (to pluck a known example out of the air.)” “Server can have one or more roles,” added Viking-Ice. “There is no doubt about that.” “But we need to be clear what we test in that world,” said nirik. “Yes,” agreed mitr. sgallagh added, “As I said above, I think it must be possible, but we can probably get away with stating that we only test each role in a vacuum.” “We chose a role and we test cover that role,” said Viking-Ice. “Alternatively, when/if we get automated tests,” said mitr, “doing a ‘full install’ and running all the tests on it should be reasonable – but let’s not commit do doing manual work twice.” Evolution asked, “Do we document roles that obviously conflict?” “I would say not,” answered Viking-Ice. “Well in some cases you can in some others you cannot,” simo answered. “In freeipa we use mod_nss… so you won’t be able to use it with another program that depends on mod_ssl. That may change in time to avoid issues, and fedora server contribution may actually help smooth those issues in some cases.” sgallagh also answered, “That would still require testing all of them together to learn whether they conflict.” “We can only guarantee what we test,” said simo. “So perhaps we should start just with bare roles, and in time add explicitly tested combinations.” mizmo brought simo’s proposal to the table and it was supported by everyone: *** Regarding multiple roles on one server, we will start with just bare roles, and in time add explicitly tested combinations. *** Installation of base + roles ============================ mizmo brought up, “It looks like another concern from last week’s minutes, about multiple roles per server, was how to install the server that way.” “You install the base server ( which I call FOSSP, )” replied Viking-Ice, “then install one or more roles.” “Yeh, that makes sense to me,” replied mizmo. “The anaconda UI actually makes this pretty easy… you can set various roles to be compatible / incompatible and let users select.” sgallagh asked, “By way of comps groups?” “Yep,” mizmo replied. “That’s the way to go in my opinion too,” said nirik. mizmo added, “If we have a better answer to comps groups or want to expand on them or fix them, though – it should be possible, I think.” “I think we can agree on this “FedoraOS Server Platform ( FOSSP ) is made available with or without an predefined server role,ready to use ks for traditional method of installation,directly into an isolated or OS container or as an whole-disk images to be used in private/public cloud as instance-store image or standalone server in the cloud itself.” “Way too many decisions in one sentence,” said mitr. nirik responded, “-1 on kickstarts.” “I think kickstart is too implementation-specific, although it’s obviously going to come into play,” added mizmo. “Kickstarts should be supported but not required,” simo added. sgallagh asked nirik, “Can you expand on that?” “Kickstarts only work at install/create time. You can’t for example install foo and then decide to add role bar later,” said nirik. “Kickstarts contain too many site-specific items.” mizmo responded, “If the role was a comps group, you could though,” pointing out how a role could be added on later. “Yes, which is why I think it’s a better solution,” said nirik. “So you’re just opposing pre-generated kickstart files we make available, rather than ‘don’t use kickstart to set up servers,’ I assume?” sgallagh asked nirik. “Yes,” nirik replied. “Nirik,” said Viking-Ice, “We install either the base server or base server + 1 ( and later as has been decide ) or more roles. We test this as is as it comes from us.” “I’d like to see it in anaconda/yum groups personally,” said Evolution. “Kickstart recipes would be good, but as a community thing maybe outside what we’re doing here.” mizmo added, “I don’t think we have a good GUI way to install groups post-install, though.” “That ‘needs to change,’” said mitr. “Mind, it’s not a matter of adding a comps group only; installing a server role should also allow easily invoking a GUI to set up that role as a group.” “That’s one thing actually I want to talk using Cockpit for, when that project finds its feet a bit,” sgallagh pointed out. “Which brings up for me how we still need to discuss personas :) ” said mizmo. Viking-Ice replied, “I think we can drop personas and target and just do the prd’s for roles.” mizmo questioned Viking-Ice, “Then how do you know how to make the decisions if you dont know who the product is for?” “Well, roles should be targeted at personas,” sgallagh said. “Where the persona may simply be “Admin that needs to run a mail server. Or more likely “Admin that needs to be able to manage a groupware suite.” “Right,” said Viking-Ice. “Our audience are administrators, and we do not care at which level or how experienced they are.” “I think we should actually be aiming to target a more junior admin than we traditionally have,” responded sgallagh. “I think it would be good to be clear about our targets,” added nirik. “What kind of personas do you have in mind?” asked simo. “Unix-savvy admin vs clueless admin? Are there any other?” mizmo replied, “Let’s pick that up after the install base + roles topic.” sgallagh said, “For post-install, I was personally envisioning doing something like canned ansible recipes (formulas?)” “Again, tho, the problem is that they are very site specific,” responded nirik. “BTW you can add an role later ( After install via yum or dnf foo )” said Viking-Ice. nirik replied, “If they are comps groups, sure… but if they are, why not use that in the installer to install whatever the person wants? Or they can write their own kickstart.” “Can we agree on goals instead of technology first?” asked mitr. mizmo, sgallagh, and simo agreed to this. Viking-Ice continued, “We provide vm’s and best out of the box experience ( which can be read as few steps to get it going.)” “I think we need to decide only if we want to make it easy to install a ‘role’ and when. Only at anaconda time or at any time?” said simo. mitr proposed a couple of goals: * “Goal 1: automated (“mass”) install within a larger Linux infrastructure (e.g. PXE is an option, may have LDAP/IPA.)” * “Goal 2: manual install without a supporting infrastructure (e.g. the very first Linux server).” After that we ended up hopping on an etherpad (via piratepad.net) and working through some goals. We got a good set of initial goals and deferred some goals for later discussion, then promoted the document to the wiki, here: https://fedoraproject.org/wiki/Server/Proposals/Server_Roles/Installation_G… We ran out of time and decided not to continue past the original allotted time this week. Further discussion about server role installation goals will take place in this thread on the mailing list. Meetbot Minutes: =============== Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-12/fedora-meeting…

2 4

Goals for Server Role Installation
by Máirín Duffy 12 Nov '13

12 Nov '13

Hi, In today's meeting we had a discussion about Server Role installation goals. We had a pirate pad running during the meeting where we came up with some of those goals. Can you please look through what we came up with and provide feedback? If you have suggestions for additional goals we should have, can you suggest them in this thread as well? Here they are: https://fedoraproject.org/wiki/Server/Proposals/Server_Roles/Installation_G… Thanks, ~m

1 0

Suggestions for Nov 19 Agenda
by Máirín Duffy 12 Nov '13

12 Nov '13

Hi, 1) Personas (mizmo) - https://lists.fedoraproject.org/pipermail/server/2013-October/000333.html 2) Server Lifecycle Proposal (sgallagh) - https://fedoraproject.org/wiki/Server/Proposals/Server_Lifecycle 3) Updates and Testing Proposal (nirik) - (https://lists.fedoraproject.org/pipermail/server/2013-November/000489.html 4) Server Role List Proposal (Viking-Ice) - https://fedoraproject.org/wiki/User:Johannbg/FOSSP#Server_Roles.2C_Technolo… ~m

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server November 2013