User: Password:
|
|
Subscribe / Log in / New account

Grover: Fedora for short-lifespan server instances

Grover: Fedora for short-lifespan server instances

Posted Jun 4, 2013 21:30 UTC (Tue) by skvidal (guest, #3094)
In reply to: Grover: Fedora for short-lifespan server instances by mjg59
Parent article: Grover: Fedora for short-lifespan server instances

Actually, bringing it up is not the issue. It is the reality that we don't have a lot of people for the number of services we have to maintain. So bringing it up is not the most difficult - it is being in CONSTANT UPGRADE mode the rest of the time.

If none of our CM tools ever evolved and none of the systems tools ever changed - maybe we could spend 100% of the time in app-upgrade mode.

but the tools do change.... .all the time.

-sv


(Log in to post comments)

Grover: Fedora for short-lifespan server instances

Posted Jun 4, 2013 21:41 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

If it could be brought up on F19 in a reasonable amount of time, I'd expect the amount of effort required to then get it running on F20 (and so on) would be pretty low. But I don't think it could be brought up on F19 in a reasonable amount of time.

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 4:13 UTC (Wed) by dlang (subscriber, #313) [Link]

and this is exactly why a lot of sysadmins dislike the idea of using Fedora for their systems.

with a 12 month support cycle and a 6 month release cycle, you have to upgrade every release or you end up unsupported (most of the time this isn't a problem, but are you willing to bet your job or career or business on it?)

Ubuntu with it's 18 month support cycle at least allowed you to skip every other upgrade if you wanted to (and now that they are shortening the support cycle, they are in the same bad position as Fedora)

this is why people use the LTS/Enterprise distros.

They have a business to run, and for that business the OS they are running on is a tool that needs to enable them to get work done with as little cost (in money and manpower) as they can get away with. it's really rare that an upgrade gives you a very significant benefit, but it's unfortunately very common for new versions (especially of Fedora) to include bleeding edge features that aren't really ready yet.

the behaviour of some far too many user tools to make major re-writes and redesigns in an upgrade hurts the reputation of all software.

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 5:21 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

You got some details wrong.

https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#...

So, you don't have to necessarily upgrade every release. Every *other* release would be ok since say Fedora 17 would be maintained till Fedora 19 is released and you can afford to skip Fedora 18.

Ubuntu (not LTS) schedule doesn't allow for that and LTS is supported for 5 years while RHEL is supported for 7 to 10 years.

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 5:33 UTC (Wed) by dlang (subscriber, #313) [Link]

since it takes time to test a new version and roll it out, you need to have the support for the old version extend at least a couple months past the release of the new version.

So I stand by my statement that 12 months of support with 6 month releases means that you have to upgrade every release to remain supported.

Ubuntu LTS with 2year release cycle and 5 years of support allows you to skip releases there as well. But I would actually argue against doing so, there are enough new features over two years, and enough bugfixes (most of which are not going to be backported, to Ubuntu or RHEL) that after two years or so you really should upgrade.

RHEL being supported for 7-10 years is a bug, not a feature as far as I'm concerned :-)

It allows people to stay so far behind that when the support finally does run out they have probably had close to complete turnover of their staff (very possibly a couple of times) and so end up without anyone around who knows how the apps/systems were actually built. This puts them in a real bind when they are forced to upgrade.

Besides, I just don't believe that any company has the resources to properly backport all the bugfixes over that much time. Linux development is just too rapid.

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 6:16 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

The maintenance schedule is still approx 13 months or more depending release cycle and not a fixed 12 despite whatever you claim. How long it takes to test a new release depends on when you start testing and what you are going to use it for. One could test it in the time between say beta and final release using the test candidates and deploy it pretty much right after a new release since only blocker bugs are fixed during this time. Even some enterprise customers do this with EL.

Red Hat's lifecyle was extended to support paying customers and reach parity with the competition and can hardly be called a bug considering how many years it takes for some certifications. Have you looked at how long Windows on the server is support or Solaris is supported? Also Red Hat doesn't promise to backport all bugfixes. Instead the support progressively gets confined according to https://access.redhat.com/support/policy/updates/errata/. So the last point doesn't apply.

Grover: Fedora for short-lifespan server instances

Posted Jun 6, 2013 20:17 UTC (Thu) by dag- (subscriber, #30207) [Link]

It is a weird idea that it's better to renew your OS every 2 years just because people and knowledge may not be around after 4 years or more. The cost of renewing 4000 Linux systems every 2 years is just enormous. We're not talking about 4000 identical Linux systems, but about 700 different business projects with specific needs and possibly custom software.

In large enterprises a renewal cycle used to be 4 years, which is the lease-time or support time of hardware, with virtualization becoming more the standard rather than the exception, renewal cycles of 8 to 10 years become a possibility.

That is a good thing. If you are concerned about knowledge and people leaving the company, start to document and evaluate documentation. Make this part of the process, rather than an afterthought.

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 5:22 UTC (Wed) by agrover (subscriber, #55381) [Link]

Either a long- or short-term distro isn't going to be right, but with virtualization you can choose on a per-service basis, based upon the estimated lifetime of the instance.

What a lot of people are doing today is taking RHEL (or Centos) and updating the parts they need manually. What I was really trying to say was that instead of doing that, it might be less work to use a distro that *had* the up-to-date dependencies already (still use LT distros for other stuff) since the instance will be sure to be discarded before the short support window becomes an issue.

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 5:24 UTC (Wed) by agrover (subscriber, #55381) [Link]

e.g. Netflix average instance lifetime is 36 hours.

Grover: Fedora for short-lifespan server instances

Posted Jun 5, 2013 5:39 UTC (Wed) by dlang (subscriber, #313) [Link]

average lifetime is misleading. They have very sharp peaks and so I'll bet that the vast majority of their instances have a lifetime of one hour, which brings down the average without addressing the problems.

Virtualization in itself doesn't help you, you still have to do all the testing for the new version that is running in the VM (far too many people just upgrade the hosts, leaving the VMs running old versions)

automated deployment of system images, be in in VMs or on bare metal _does_ go a long way towards solving this problem.

but automated deployment doesn't have to be restricted to VMs

and many people do cloud and VM systems without automated deployment.

and the latter end up wondering what the hype was all about and can't understand why they don't see the huge benefits that they were promised.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds