server November 2013

server@lists.fedoraproject.org

28 participants
36 discussions

Thoughts on Fedora Server lifecycle
by Stephen Gallagher 11 Nov '13

11 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Related to my earlier mail "Server Admins: Why not Fedora?", I wanted to specifically discuss some lifecycle ideas. Every few months, people start shouting again for a "Fedora LTS" and people generally respond with "we couldn't support that with volunteers" or "go use RHEL/CentOS/SL". Suppose for a moment that we did things a little differently in the Fedora Server. We don't want to get out of sync with the release cycle set by the Base Design WG, certainly. But at the same time, I think we can come up with a fairly simple way to maintain the Fedora Server for a longer time period. I'm going to propose a lifecycle of eighteen months (with slight extensions for slippage) as follows. Let's start talking about Fedora Server 1.0 (rather than Fedora Server 21). In my view of the world, we would build the Base Design as Fedora 21, Fedora 22 and Fedora 23 following mechanisms not terribly dissimilar to the present-day model. We would then create the Fedora Server atop this, delayed by a small amount < 1 month). We would use the latest Fedora Base bits as the platform and sync our pieces atop it at regular intervals, aiming for a finalized release every eighteen months. I spent the last hour trying to draw up a decent timeline graphic, but I am terrible at this and so I will instead attempt to explain it in text. Please bear with me. Let's start the discussion from Fedora 21. We would follow the Fedora 21 process closely until the base design is declared final (much as current Fedora is now). Ideally at the same time (but possibly delayed by up to a month), we would release "Fedora Server 1.0 Preview 1". This would be a complete, installable server operating system, but make it clear that it's a preview release that may not represent the final product. At Fedora 22, we release "Fedora Server 1.0 Preview 2", with the same caveats. However, at Fedora 23, we release "Fedora Server 1.0". At this time, we agree to freeze the interfaces and make clear demands on backwards-compatibility. For the remaining life of Fedora Server 1.x, it will be a stable platform (and understood to be extremely conservative with its updates). At Fedora 24, we now release two things: "Fedora Server 1.1", which will just be an updated installer with the latest versions of any package updates that have occurred in the standard install since Fedora Server 1.0". We will also release "Fedora Server 2.0 Preview 1", following the same guidelines as above. Fedora 25 would offer the "Fedora Server 1.2" updates roll-up and "Fedora Server 2.0 Preview 2", and finally Fedora 26 would offer only "Fedora Server 2.0" as install media. At this time, Fedora Server 1.0 would become "security-fixes only" for the six months until Fedora Server 2.1 (to allow overlap to upgrade). As of Fedora Server N.1 of any release, the N-1 series is abandoned. So yes, that sounds ambitious, but what do you think of the idea? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJz804ACgkQeiVVYja6o6P6KACgmbiOeJ9yE9WLQ5Phb9G9lvcV deQAoKAfmY9pp805MUQef26QObv71/FT =H7Dc -----END PGP SIGNATURE-----

14 65

updates and testing instead of lifecycle
by Kevin Fenzi 09 Nov '13

09 Nov '13

So, instead of trying to tweak the life cycle, how about another alternate approach: Short term/f21: - For those 'featured stacks' that we are going to integrate and test, and all there deps, we setup some new group for Bodhi ("server-critical-path"). - We setup new rules/critera/test plans for when updates are allowed to go stable that are in this group. (open to ideas on what this would be exactly, I suspect we would want to rope in maintainers of those components) This would allow folks to know that if they install the release version and apply updates everything will continue to work. - Look at default partitioning/setup that will let us use lvm thinp and yum pre/post transaction snapshots for extra paranoia. This may require us to decide that say /srv is where most user data is by default. - Work to improve fedup support for server use cases (remote machine, etc) and make sure Fn->Fn+1 for server case is heavily tested and rollbacks are supported. (This may well need additional developer time) - Create comps groups for each 'featured stack' of things, so they can be selected at install time or installed later. Ideally we would test all of these, but since any combo of them could be installed at once, we may have to pick and choose. Possibly "each feature by itself" and "all features at once" would be easy cases to start with. Longer term: - Add some logic to bodhi (or wherever) that would note updates that require a 'restart' in addition to a 'reboot'. Or setup some way to notify admins things that need restart. (email to root from needs-restarting?) - Perhaps make a server specific 'initial setup' that sets some server specific things instead of making a local user. (root email alias, logs retention, etc. - Improve server docs a lot. Possibly include a best practices doc. Especially note new features like cgroups, journald, etc. - Grow out more featured applications. - Decide on and work on integration of our applications with base stuff like auth backend, database, CM, monitoring, backup solution, log monitoring, intrusion detection, and probibly a bunch of other things. - Look at all the container solutions (possibly this is with other working groups) and see if any of them should be 'featured' and made well integrated. Possibly someday the containers take over for the normally installed versions of applications. Thoughts? kevin

2 2

Server Admins: Why not Fedora?
by Stephen Gallagher 09 Nov '13

09 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One of the oft-repeated statements about Fedora is that it's "not good for running a server". Clearly, as we embark upon a mission to change that fundamental belief, we need to start addressing the problems that make Fedora unsuitable to so many people. I propose that a good place to start here is to carefully enumerate the reasons people elect not to use Fedora in their server environments. Let's start by gathering the surface problems (in some cases, the cargo-cult explanations) and look into what is the real underlying problem and how we can fix it with the Fedora Server offering. To get us started: * Fedora moves too quickly! Historically, Fedora's policy has always been to be among thefirst to ship new technology (whether or not it's ready, but that's another discussion). The problem with tracking rapidly-moving upstreams is that they are not all created equally. Some upstreams (e.g. glibc) obsessively avoid backwards-compatible changes between versions. These are the upstreams that Fedora's current approach works well for. These tend to be the low-level features of the operating system that understand that compatibility == relevance. No one will build atop these systems if they don't have a guarantee that it will continue to work. Other upstreams (e.g. much of the Ruby and Java community) tend to focus more on constant innovation without consideration of backporting. This allows them to make bigger changes much faster, but at the cost of constant churn and difficulty to distribution packaging. These are the systems that normally expect consuming applications to just bundle the exact version of the library known to work. This is where we get into the "Fedora moves too quickly" area of things. Whatever we're shipping in the standard location on-disk tends to be preferred by the applications, and if it isn't the same version that upstream wanted to bundle, all bets are off. * Fedora moves too slowly! This seems like the inverse of the above, but this is what happens when certain packages are intentionally kept on an older version in order to maintain compatibilitity with some high-value application in Fedora. A classic example of this is 'v8'. The v8 version in Fedora is maintained to match what Node.js upstream supports, even though it is rather old and lacking many of the new features. Unfortuntately, if Fedora pulled in the newer version, it would break hundreds of other packages. This causes issues with people who are trying to build software (such as Chromium) that depends on the latest version. * Fedora has too short of a lifecycle! This is a very common one. The idea here is that administrators who are deploying a server to provide functionality to their infrastructure or critical apps to their users don't like to change the underlying operating system very often. With Fedora, they need to upgrade every thirteen months (and more often if they want to avoid issues that may crop up while going from version N to N+1 and then N+2 all at once). In many environments, the amount of compatibility and functional testing that would be needed to move their infrastructure exceeds what they could hope to accomplish on such a frequent upgrade cycle. I'm sure there are other reasons and I'd like to hear them. Also, for those of you who *do* use Fedora in production, I'd like to hear the reasons why you chose to do so. What did Fedora gain you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJz26kACgkQeiVVYja6o6PjoACfehQ4A/1OnKMpSTpCgAESPirO HOYAn2umcZLfQlY4MY+832noJIF28Hv6 =zfYV -----END PGP SIGNATURE-----

17 52

Server Working Group Blog
by Máirín Duffy 08 Nov '13

08 Nov '13

Hi folks, I set up a blog for the Server Working Group. It is located here: http://fedoraserver-wgblog.rhcloud.com/ I set up OpenID auth, so if you'd like to create an account on it, anyone is welcome. Just fill in your Fedora open id (e.g., I put in duffy.id.fedoraproject.org and I can auth that way): http://fedoraserver-wgblog.rhcloud.com/wp-admin Once you log in using your Fedora openid for the first time, it'll give you a user on the system, and then I can go in and make you an editor or an admin or whatever. Let me know. I would definitely appreciate some help in terms of volunteers to be admins in case I get eaten by a raptor or what not. I also set up the blog to be aggregated on Planet Fedora and transferred the two existing blog posts over to it, back dated appropriately. Thanks, ~m

3 3

introduction
by Renich Bon Ciric 06 Nov '13

06 Nov '13

Hey guys, Glad to see a Server SIG for Fedora... finally! I have several servers on Fedora and have upgraded/reinstalled since 5 years ago probably. I am definitely interested in headless and kickstarts and cli tools. -- It's hard to be free... but I love to struggle. Love isn't asked for; it's just given. Respect isn't asked for; it's earned! Renich Bon Ciric http://www.woralelandia.com/ http://www.introbella.com/

1 0

Updated & WG-Approved Governance Charter
by Máirín Duffy 06 Nov '13

06 Nov '13

Hi folks, I've updated the governance charter with the changes and language we agreed upon during today's meeting, and I fixed a few spelling/grammatical typos as well: https://fedoraproject.org/wiki/Server/Governance_Charter I've updated the admon note at the top stating that we've approved the document but it is not yet approved by FESCo. Stephen, would you mind passing this over to FESCo since you are the FESCo liaison? Thanks, ~m

4 7

Re: Draft Product Description for Fedora Workstation
by Paul W. Frields 06 Nov '13

06 Nov '13

On Fri, Nov 01, 2013 at 10:24:20AM -0400, Christian Fredrik Kalager Schaller wrote: > Hi everyone, > Attached is the draft PRD for the Workstation working group. The > proposal tries to be relatively high level and focus on goals and > principles, but I have included some concrete examples at times to try > to provide some clarity on how the goals and principles could play out > in practice. > > I hope the community at large will take the time to read through it and > provide feedback so that when the working group meet next we can use > that feedback to start tuning in on the final form of the PRD. Here's a statement we may need to better clarify on p. 3: "The working group will also specify policies in terms of branding, themeing and desktop graphics." I think we should be clear that any branding efforts need to fit into the overall branding framework of Fedora. We should be careful to avoid having branding diverge between the products to an extent that makes it harder for us to identify them as part of a family of Fedora products. In my time as an FPL, I worked extensively with Fedora folks on trademark and brand guidelines. I suspect Robyn has done quite the same wherever possible. It would be a step backward to make it harder for people to readily identify any of the Fedora products with Fedora. This is really a suggestion for all the working groups, so I'm cc'ing server@ and cloud@ lists too. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com

1 0

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

06 Nov '13

Hi folks! Below find a summary of yesterday's meeting. You can also read it in blog format at http://blog.linuxgrrl.com/2013/11/05/fedora-server-working-group-nov-5-meet… . 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 ====== * Finalizing the Governance Charter * Is Fedora Server One Product? Finalizing the Governance Charter ================================= We had a discussion about two pending issues with the governance charter and another issue regarding the use of the word 'quorum' in the document before ultimately approving it. Group Membership ---------------- Should the voting members of the server working group should be required to be members of other Fedora teams as specified by their seat/slot? We came to agreement after this discussion that it made sense to drop the group mappings for now, but to also be sure that we added a note to the membership section that we encourage involvement from all parts of Fedora. Term Length for Voting Members ------------------------------ Should membership as a voting member on the server working group be unlimited / at will or should there be terms and elections/votes inbetween? We agreed on a proposal that Nirik put forward that we would have indefinite terms with periodic (every 6 months) confirmations and that we would also revisit that decision in 6 months' time since we don't yet know "a) how long we exist, b) how many non voting active people there are in 6 months, c) if we need more fresh voting members or if as Viking-Ice notes the active people in the community would be enough for that.” Quorum ------ mitr pointed out that the charter said we must have a quorum of 5 people to vote, which means the majority of 5 people (which is 3) positive votes would be required to agree to something in a vote. The intention behind the statement was to require 5 positive votes, regardless of how many people were present at the meeting, so the verbiage was updated to reflect that and all agreed to it. Governance Charter is Finalized by Server WG -------------------------------------------- sgallagh will bring it to FESCo for review and approval. Is Fedora Server One Product? ============================= We didn't finish this discussion, so it will probably have to be brought back up next week. This was a very active and interwoven discussion, so here is my best attempt at summarizing it; I hope it's a fair summary: Terminology Trouble ------------------- We seem to have a lot of confusion about the term 'product' vs the term 'role' - if you eliminate both those terms and replace them with 'thingy' then we seem to agree on a lot more things than it appears on the surface. I don't think we came up with viable terminology that made sense to everybody, though. Shared Components ----------------- We all agree - whether the term 'product' or the term 'role' was used - that they will share kernel, booting, basic libraries, and choice of configuration/management/etc. Preferred/Featured Technology Choices ------------------------------------- It was proposed that we would make technology cohices about what is the single supported way to do something (e.g., postfix for mailservers) but users will not be precluding from installing alternatives (e.g., qmail for mailservers), they will just get less support for it. There was concern about the usage of the term 'support' and the term 'featured' was suggested, and I didn't see any other discussion about this. Multiple Roles Per Single Server -------------------------------- There was some disagreement about whether or not multiple roles/products could be installed on the same server and whether or not something like this was possible. I don't see much resolution to the conflict though, I think the discussion died off for lack of time to resolve it. Getting A PRD Started --------------------- There was a disagreement about whether or not we needed one PRD with all of the various roles/products in it, or whether we needed one PRD per role/product. Both sgallagh and nirik proposed that we put together a PRD with separate chapters with the option to split it up into different documents later if necessary. There was some discussion about what parts of a role/product PRD would be in the upstream's scope and what would be in our scope (modification and integration to meet our goals would be in our scope.) Then there was discussion over what a PRD is for. I think the conclusion there was that it was to describe 'a common base platform with feature application stacks built on top of it' to FESCo in order to get their approval. 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-05/fedora-meeting… Full set of meetbot links: Meeting ended Tue Nov 5 18:03:12 2013 UTC. Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting…

1 0

Call for Agenda for 2013-11-05 Working Group meeting
by Stephen Gallagher 06 Nov '13

06 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm very sorry for the late notice on this, but we only just finally settled on the time for this meeting[1]. Please submit agenda requests as replies to this email. Also, I have a one-time conflict with this meeting, so I would like to politely ask that Máirín please run the meeting[2] and record the discussion as she did so well last week. I will try to lurk and respond occasionally during my other meeting. [1] https://lists.fedoraproject.org/pipermail/server/2013-November/000424.html (Tuesdays at 1600 UTC) [2] http://fedoraproject.org/wiki/Zodbot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ4MkgACgkQeiVVYja6o6NkQwCgnRJHb3G2EfesiLjELtat9A73 +FMAoJYAUvbq2rPJ/+cwrqptmAomyA/c =pYMj -----END PGP SIGNATURE-----

5 4

Server WG meeting minutes 11-05-2013
by Truong Anh Tuan 06 Nov '13

06 Nov '13

Hi everyone, I think it's worth to send the meeting minutes to the list, especially for people who missed it. Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting… ====================================================== #fedora-meeting-1: Server Working Group Weekly Meeting ====================================================== Meeting started by mizmo at 16:02:30 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting… . Meeting summary --------------- * roll call (mizmo, 16:02:39) * agenda (mizmo, 16:05:11) * LINK: https://lists.fedoraproject.org/pipermail/server/2013-November/000425.html (mizmo, 16:05:38) * Finalizing the Governance Charter (mizmo, 16:06:58) * LINK: https://fedoraproject.org/wiki/Server/Governance_Charter (mizmo, 16:07:13) * AGREED: In the governance charter, we will drop group mappings, with a note saying we'd love involvement from any parts of the project. (mizmo, 16:23:41) * Finalizing the Governance Charter: Term Limits (mizmo, 16:23:58) * AGREED: We'll add a section to the governance charter setting 6-month membership confirmation periods, but we will also revisit that decision in 6 months time based on the community activity, how long we intend to exist, etc. (mizmo, 16:51:49) * AGREED: 'Quorum' for our purposes is at least 5 '+1' votes, and is not proportional to the number of members attending the meeting where the vote takes place. (mizmo, 16:56:31) * AGREED: (revision) The number of votes required to pass a vote is at least 5 '+1' votes, and is not proportional to the number of members attending the meeting where the vote takes place. (mizmo, 16:58:10) * ACTION: mizmo to take agreed points and edit the governance charter (mizmo, 17:00:08) * AGREED: We'll stay and work through more items on the agenda (mizmo, 17:02:39) * Is Fedora Server One Product? (mizmo, 17:03:04) * LINK: https://fedoraproject.org/wiki/Server/Product_Requirements_Document (mizmo, 17:09:18) * ACTION: mizmo to set up short term / long term goals document on wiki (mizmo, 17:45:40) * AGREED: Fedora Sevrer is a common base platform with 'featured application stacks' built on top of it. We commit to produce, test and distribute these application stacks. (mizmo, 17:45:51) * AGREED: Our primary deliverable for January should be the definition of how we're going to prepare the platform and the requirements for an application stack to be promoted to first-tier inclusion. (mizmo, 18:00:40) * AGREED: (revised) Our primary deliverable for January should be the definition of how we're going to prepare the platform and the requirements for an application stack to be promoted to featured status. (mizmo, 18:02:02) Meeting ended at 18:03:12 UTC. Action Items ------------ * mizmo to take agreed points and edit the governance charter * mizmo to set up short term / long term goals document on wiki Action Items, by person ----------------------- * mizmo * mizmo to take agreed points and edit the governance charter * mizmo to set up short term / long term goals document on wiki * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mizmo (190) * Viking-Ice (156) * nirik (112) * sgallagh (63) * mitr (59) * tuanta (23) * Evolution (7) * zodbot (6) * kde_tony (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot Kind regards, Tuan

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server November 2013