[cgl_discussion] RE: [cgl_specs] Use case - Live patching

[Howell, David P]

I would agree that this is a known common practice for the telco 
market. It is reasonable for a distro to say that unauthorized 
patching of their supported base files is not supported, but if
the patching is done to user APPs, middleware, or via a distro
supported patching method with tracking and rollback, where is 
the issue?

The reality is that for many applications downtime is evil, and 
patches to complex software implementations are inevitable. Done 
right and with a distro's support, it seems that an approach can
work well to provide what is needed. 

There are enough implementations of live patching around, can't 
we build a case from this that we can define an implementation 
that distros can feel comfortable with? With constraints, where 
are the flaws in the proposed implementation that lead to the 
statements that Ralf made below?

Thanks,
Dave Howell
  
david.p.howell at intel.com
 
-----Original Message-----
From: Cress, Andrew R [mailto:andrew.r.cress at intel.com] 
Sent: Monday, March 28, 2005 11:07 AM
To: Corey Minyard; Ralf Flaxa
Cc: Takashi Ikebe; cgl_tech_board at groups.osdl.org;
cgl_specs at groups.osdl.org; cgl_discussion at lists.osdl.org
Subject: RE: [cgl_specs] Use case - Live patching

Hmmm.  I see a clear difference between "Live Updates" (updating the
kernel and other base files via binary rpms, while live), and "Live
Patching" (source patch updates, while live).  

In the first case, support can be maintained through rpm versions, and
the binaries are a constant for integration testing.  

In the second case, there might not be as much rigor in versioning, and
there are lots more potential issues in re-building a kernel from
source, especially for the uninitiated system admin.  

Other Unixes do the first, but not the second, so the rules are less
well-established.
Both are doable, but the second involves more risk.

Andy

-----Original Message-----
From: Corey Minyard [mailto:cminyard at mvista.com] 
Sent: Monday, March 28, 2005 10:06 AM
To: Ralf Flaxa
Cc: Takashi Ikebe; cgl_tech_board at groups.osdl.org;
cgl_specs at groups.osdl.org; cgl_discussion at lists.osdl.org
Subject: Re: [cgl_specs] Use case - Live patching


Why do you think it is evil?  It is standard practice in most large 
telecom systems as it improves availability.

-Corey

Ralf Flaxa wrote:

>Speaking for SUSE/Novell I can at least say that live patching is evil
>and would never be considered supported. How shall you guarantee
support
>or certification with such a mechanism in place?
>
>	Ralf
>
>On Mon, Mar 28, 2005 at 11:14:50AM +0900, Takashi Ikebe wrote:
>  
>
>>The following is a use case for a Live patching.  This
>>addresses AVL10.0 Live patching on CGL Specification 3.0.
>>Please feel free to comment / suggestion.
>>
>>Takashi.
>>----------------------------------------------------------------------
-------------------------
>>Description
>>OSDL CGL specifies that carrier grade Linux shall provide the
mechanism
>>for dynamically replacing the symbols of a running process without
>>restarting. Dynamic replacement of symbols allows a process to access
>>patched functions or values without restarting and can improve process
>>availability.
>>
>>Desired Outcome
>>Mainline kernel acceptance or distro acceptance
>>
>>Participants/Roles
>>System administrators setup the requirements on installations. On
>>operation, system administrators apply patch with the requirement.
>>
>>Scenarios
>>On operation, system administrators apply patch with the requirement
as
>>following scenario;
>>1.System administrators make patch file from diff file or new
version's
>>source code.
>>2.System administrators load patch to the process with provided live
>>patch tool.
>>3.System administrators activate patch to the process with provided
live
>>patch tool.
>>4.Confirm that the patch is correctly applied or not.
>>
>>Implementation Notes
>>The requirement need to have following functions;
>>- The function which loads the patch file to target process's memory
area.
>>- The function which overwrites the branch operation code to the
patch,
>>on the entry point of  target process's functions which wants to fix
by
>>patch.
>>- The function which restores overwritten branch code.
>>- The function which unload the patch files.
>>Through above functions, the requirement realize on-line patch to
target
>>process.
>>The requirement need to provide on-line patch even if the process is
>>multi-thread model process, or environment is SMP, and stop time of
>>target process should not over  100 milliseconds.
>>
>>References
>>Pannus project: http://pannus.sourceforge.net/
>>Live patching implementation:
>>http://prdownloads.sourceforge.net/pannus/pannus_en.pdf
>>
>>
>>-- 
>>Takashi Ikebe
>>NTT Network Service Systems Laboratories
>>9-11, Midori-Cho 3-Chome Musashino-Shi,
>>Tokyo 180-8585 Japan
>>Tel : +81 422 59 4246, Fax : +81 422 60 4012
>>e-mail : ikebe.takashi at lab.ntt.co.jp
>>    
>>