Server/Proposals/Server Lifecycle

This is a draft proposal.
This proposal is currently being discussed on the Thoughts on Fedora Server lifecycle thread on the server mailing list.

Resources

This proposal comes from the following thread started by Stephen Gallagher on the server mailing list:

Thoughts on Fedora Server lifecycle

A relevant earlier proposal that is similar is Tom Callaway's Overhauling the Fedora Release Model talk from FUDCon Lawrence in January 2013.

Overview

This proposal is for a lifecycle of eighteen months (with slight extensions for slippage) as follows:

• We will start with Fedora Server 1.0 (rather than Fedora Server 21).
• 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.
• Up until the final release, each N preview release should be just a snapshot matching EXACTLY the Fedora Base release at that time. It should be usable (but probably won't get any extra QA time over the Base release). Then at the N.0 final release, it should get branched away and kept more tightly controlled. This doesn't mean that it can't get updates out of the Base branches, but they should be merged in when they're ready, not blasted in from the firehose.
• Each N.0 release essentially goes into maintenance mode at the moment of it's stable release. Real new functionality should head to N+1 previews and only get pulled back to N.x if it makes sense and someone is willing to do the work.

Detailed Walkthrough Of Timeline

Source SVG

• 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."
• 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.

Questions & Answers

1. How would you handle upgrades between N-1 -> N ?
   • Well, that's part of the point of the .1 releases too. That's the point at which we should be re-testing fedup to major releases. Within a release, fedup shouldn't (must not?) be required. I.e. Fedora Server 1.0 -> 1.1 should be safe and clean with just 'dnf update', but 1.1->2.0 should go via fedup. (sgallagh)
2. Is Fedora Server going to have its own package repository?
   • Yes, the same way that Fedora 19 and Fedora 20 have different repositories. It's nothing new. (sgallagh)
   • This is quite a bit different, in that it's not tracking a fedora release. This would potentially mean "yet another" target for builders and 3rd party repos to support. I would much rather track the current fedora releases with better packaging, usability etc than spawn an entirely new structure. (Evolution)
3. In Fedora Server 1.0 you will have to install packages built for Fedora 21, however if the product that produces them stays on a short release cycle, by the time we go 1.0 there not even security updates anymore for them. So what do we do ? We force other products to do security updates for 24 months ?
   • Up until the final release, it really should be just a snapshot matching EXACTLY the Fedora Base release at that time. It should be usable (but probably won't get any extra QA time over the Base release). Then at the N.0 release, it should get branched away and kept more tightly controlled. This doesn't mean that it can't get updates out of the Base branches, but they should be merged in when they're ready, not blasted in from the firehose. (sgallagh)
4. "Updated installer"? Unless you mean something not anaconda, I'm not sure you'll be able to update the installer in Server 1.1 with the installer in Fedora 24, given that Fedora 24 is back to "unstable-ish". Why isn't 1.1 using the installer from 1.0?
   • I was mostly thinking of newer anaconda enabling more hardware/choices, but I'm certainly flexible here. If the costs outweigh the gains, obviously that's the wrong choice. (sgallagh)
   • About the only option really doable here is to have someone pick up Server 1.0 anaconda and do backports for pieces of functionality that were added and are still covered by the underlying packages in f21-f23. It would be a micro-fork of anaconda at that point though. Definitely something to discuss with those developers. (jboyer)
5. When Fedora Server 1.0 forks, that is maintained in addition to building towards Fedora Server 2.0 on the now unstable Base? This is essentially the idea that Spot pitched at FUDCon Lawrence. If the resources to pull it off are attainable, I think it will go a long way but the requirements to do this shouldn't be underestimated.
   • We're talking about a much smaller version of the Fedora Project than he was. Here we're talking about a highly-constrained set of packages that makes up the Server default install, which we should be striving to keep as small as possible. This will keep our resource needs down with regards to maintenance.
   • Well, Base + Server. Base will be smaller, but still fairly sizeable or it woudn't be usable as a Base. So at the point you fork off Server 1.0, you're maintaining both of those package sets in Server 1.0. (jboyer)
6. _Default_ install only? What about the "500 applications" (to use Jóhann's terminology) that are a part of the wider server universe but not the default install? Where do they live? Are they released/maintained as part of Server N.{1,2}, only not part of the default install? Or are they outside somewhere in the Commons (which would require both Base and Commons to follow the Server branching model, or at least to give ABI guarantees that track the Server branching model)? (mitr)
   • I think we need to be involving the Base Design and Stacks in this discussion. My *hope* from those projects is that they will be providing a sensible solution for this. (And I'm not going to assert what that solution is myself right now; I know it's going to have to become some sort of balance between packaging purity and carrying the dependencies an application/service needs). (sgallagh)
   • I'd very much prefer the Fedora Server to be a tightly-integrated operating system providing a few select services by default that are REALLY well tested and work together. Beyond that, we should be a platform for serving third-party services (and that means both Commons and commercial). (sgallagh)
7. How is this going to work without impacting the contributors working on Fedora Base?
8. What resource requirements will make this feasible?
9. When you say "few select services by default" do you mean installable by default or installed by default?
   • Installable by default, sorry. I'm talking again about the concept of server roles. Any of those that we offer should be tightly integrated and dead simple to set up and get something that works. (Getting something tuned to their needs after that can be more complex, of course). I'd like to see us focus on a few specific niches where we can have a big impact and then expand those supported roles over the course of a few preview releases, finalizing them for each stable release. (sgallagh)
10. What are our short-term deliverables?
11. What are our long-term deliverables?
12. Are we planning a netinstall iso type thing thats the bare needed to run yum to install other packages? (This may be something the base group makes?)
    • I absolutely think this is something we should focus on. From the CentOS side, we have a ton of interest in our minimal iso. There are a number of folks who use it in conjunction with puppet/cfengine to deploy things. This may potentially bleed into (or overlap with ) the cloud sig folks. (Evolution)
13. Are we planning an install dvd that asks folks what to install from a list of things we ship on the dvd (and optionally the net)?
14. Do we make a livecd type image that has a curated selection of server services we want that can be used live or installed?
    • Is there a use case for a livecd server setup? There's probably something for this, but I'm interested in what others think. (Evolution)
    • I really don't see this. LiveCDs are going to run slower and their use for testing isn't as useful in the server case as they would be for people thinking about switching desktops. For servers you are going to want to test things like you are going to run them in production. They might have some specialized use where you want to run from read only media as a security measure, but I don't think that is common enough to worry about. (Bruno Wolff)
15. What is our preferred delivery method?
    • I think our primary delivery method would be ks preferable fetchable from netinstall iso and stored in git ( that ks could be read from a usb stick from anaconda as well ) as well as if we cant apply your ansible/playbook proposal for it as well. (Viking-Ice)
    • Well, ks (and ansible playbooks, etc) are very flexable, possibly too flexable for this case. I suppose I could see basing things off some existing ks, but I really expect most server admins would tweak their own. Same for post install config... So, perhaps it's best for us to produce the underlying framework (possibly with a few examples) and test that and make sure it works so server admins can customize on top of that. (nirik)
    • One of the problem with Fedora is that we are to generic but with targeted products we can break away from that so I would actually say we should produce the best out of the box optimized ks/playbooks files for any given server product, reducing the steps necessary to configure/tweak/optimize/scale/secure for administrator to perform and get started. (Viking-Ice)
      • As a long term (20 year) Linux DevOps/SysAdmin I want to say that this is pretty much nirvana for me - each service installed, integrated as much as is possible with something like salt or puppet and cobbler or whatever the current install tool is, with a monitoring system looking at the machine and all its services as deeply as possible. (Neil Thompson)