Vladis, I hear ya and agree to that. Problem is I have seen big and by big, I mean biggggggggg infrastructures asking for ksplice since certain sales people of certain company introduced them to the utopia that is called downtime-less-patching-and-upgrading. And obviously, if you have worked with the CLI a bit less than most of us have already had, you get the sweet inclination to go with sales and you know, voila.
On Tue, Nov 19, 2013 at 2:16 PM, <valdis.kletni...@vt.edu> wrote: > On Tue, 19 Nov 2013 09:48:27 -0500, Soham Chakraborty said: > > I don't really think ksplice has garnered much love from upstream. > > The most common word used upstream to describe ksplice is "bletcherous". > > The reason it's disliked is because it's a poor solution for the problem. > Although ksplice-like technology was used for years to upgrade telco > switches on the fly, that was motivated by two major factors: > > 1) Nobody at a telco wants to drop dial tone while a switch reboots. > 2) Telco switches are building-sized and expensive, so HA failover wasn't a > realistic option. > > Although the first is still an issue for many sites, there's little or no > justification in 2013 for the second. > > If you're in the sort of environment where you really need the sort of > uptime > that drive you to consider ksplice, you *really* should be doing load > balancing and HA failover with heartbeats - that will not only allow you > to actually reboot each server cleanly, but *also* protect you against > blown > DIMMs, crashed system disks, and all the *other* whoopsies that can cost > you one or two nine's of reliability. > > Seriously - if you can't afford the downtime to reboot, youy can't afford > *NOT* to be doing a full HA configuration - and possibly looking at > geographic separation of the hot failover site. >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies