LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

[PATCH] Re: ipvsadm trees

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [PATCH] Re: ipvsadm trees
Cc: Wensong Zhang <wensong@xxxxxxxxxxxx>
From: Horms <horms@xxxxxxxxxxxx>
Date: Thu, 27 Jan 2005 13:44:16 +0900
On Mon, Jan 17, 2005 at 01:27:23PM +0800, Wensong Zhang wrote:
> 
> 
> On Thu, 13 Jan 2005, Horms wrote:
> 
> >On Wed, Jan 12, 2005 at 10:43:06AM -0500, Joseph Mack wrote:
> >>Alejandro Mery wrote:
> >>>
> >>>Hi, i have a machine which boot both, linux2.4 and linux2.6. i want to
> >>>use ipvs on both, what should i do with ipvsadm? can i use ipvsadm-1.24
> >>>to admin lx2.4 or ipvsadm-1.21 for lx2.4 and 1.24 for lx2.6?
> >>
> >>The way they were written you have to use a version of ipvsadm for each
> >>kernel. I would rather one giant ipvsadm that detects the kernel and does
> >>the right thing. However Horms is the one who's doing most of the 
> >>maintenance
> >>and he's happy with the way he's doing it.
> >
> >I am not sure that either of those stathements are true.
> >I would definately rather ipvsadm had the same kind of
> >semantics as modutils. That is something like this:
> >
> >You always invoke ipvsadm regardless of your kernel.
> >If you only have ipvsadm-1.21 or ipvsadm-1.24 installed,
> >then that is always run and it complains if there is a kernel
> >version missmatch. If you have both installed then ipvsadm-1.24
> >is always run, but if it detects a 2.4 kernel, then it execs
> >ipvsadm 1.21.
> >
> >Also, the current version numbers are quite aquard, especually
> >as 1.24 is used for a 2.6 kernel, nota  2.4 kernel, which one
> >may be tempted to think in error. But we are probably stuck with them.
> >
> >As for who maintains the code. I have made modifications to it over
> >time, as have others. But I always assumed that as with the kernel code
> >the maintainer was Wensong.
> >
> >I would be more than happy to make patches to implement what I describe
> >above, but I would like some feedback from Wensong first.
> >
> 
> If we merge the code of current ipvsadm-1.21 and ipvsadm-1.24 together, we 
> probably need copy all the ipvs interface between kernel and user (ip_vs.h) 
> into ipvsadm source code, so that no matter which version the default 
> kernel source is, ipvsadm can be compiled. Then, there is two places to 
> maintain for the ipvs interface, the ipvsadm source code would be 
> complicated and hard to read and maintain. In my past experience, 
> maintaining the code of using getopt and popt parsing option together in 
> one ipvsadm.c is time consuming. As long as the ipvs interface between 
> kernel 2.4 and 2.6 is different, it is hard to do it in the way.

Hi Wensong,

I think you missunderstand my suggestion. My suggestion is not to merge
the code. I think keeping ipvsadm-1.21 and ipvsadm-1.24 is fine.
Its a clean split. What I am talking about is allowing ipvsadm-1.24 to
exec ipvsadm-1.21 if it detects that is the right thing to do.

This is how modprobe and friends work, so you can have both the 2.6 and
2.4 generation tools installed. This is very useful for systems
that want to be able to run both a 2.4 and a 2.6 kernel. And is
simmilarly useful for packagers of distributions that have that
requirement.

Attached is a first cut at implementing this. I borrowed some code
from modprobe. And by default this new feature is not compiled in,
so you get the existing behaviour.

If it is compiled in, and you run ipvsadm on an a system running 2.4, 
then it will try and exec PATH/ipvsadm-1.21, else gracefully fail. It
is up to the packager or sysadmin to install ipvsadm-1.21 into
PATH/ipvsadm-1.21 and compile ipvsadm-1.24 with this new feature
if they want this functionality. Again, I am thinking of package
maintainers.

-- 
Horms

Attachment: ipvsadm-1.24.backwards_compat.patch
Description: Text document





<Prev in Thread] Current Thread [Next in Thread>