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.Kletnieks@xxxxxx> wrote:
On Tue, 19 Nov 2013 09:48:27 -0500, Soham Chakraborty said:The most common word used upstream to describe ksplice is "bletcherous".
> I don't really think ksplice has garnered much love from upstream.
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@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
