|
Hello,
On Fri, 29 Aug 2003, Ben North wrote:
> As the original author of the patch, it saddens me to say this, but
> Vinnie is absolutely correct. I never received a satisfactory answer to
> why the patch was never incorporated into the main LVS code.
The main problem is that we are not happy with the
netfilter design. OTOH, your work covers particular case (NAT)
ignoring the fact that there are other methods available. There
are so many issues that need to be handled, do you have time for
this? Because this code is going to be compiled from many
people and in different setups. We have to handle all corner cases.
I'm now looking at linux-2.4.19-ipvs-1.0.7-antefacto.patch.
I assume you will maintain this code if it is incorporated because
I'm not sure someone has the ability to test it carefully, you know,
IPVS is now both in 2.4 and 2.6 mainstream, there are already so
many tools that will cry on the smallest compatibility problem.
> It is not a large patch. Excluding comments, assertions, debugging
> printk()s etc., it adds about 10 lines of real code to the kernel
> itself, and about 50 lines to LVS for the main functionality. FTP
> handling adds about another 75 lines.
I see, it is now shorter but still not nice :)
> Also, I tried to explain very carefully exactly what it did and why.
> This was the purpose of the README I sent in. So the keeper of the
> official code would not have been 'blindly' incorporating a bunch of
> random code.
Can you send me link to the current docs and patches so I can
take a look?
> We gave it as much testing as we could at Antefacto, and Vinnie has been
> using it successfully. I believe it's a stable piece of code.
I rely on your word :)
> It seems there's enough of a demand for this functionality, so I'll ask
> the maintainers: why are you reluctant to incorporate this patch into
> the main codebase?
Noone should be against clear/nice code covering all cases.
My feeling is that may be we can live with this feature only if
it is carefully hidden into the code without breaking other
stuff :)
> What's happening now was inevitable really. I cannot really keep the
> patch up-to-date. It's unreasonable to expect Vinnie to take on the
> maintainership. For somebody fairly familiar with the codebase, I would
> guess it should be less than a day's work to produce a new patch. I
> don't have the time or equipment here to set up a development
I do not have test setup for this too :) Also, we have to
investigate the code that calls netfilter functions. In any case,
I need your comments on these things first:
- where we start? may be with 2.4?
- we can now use ip_route_me_harder instead of route_me_harder.
I agree that this is valid code but considering the fact that Netfilter
is so ugly in using the routing I'm still not sure whether to
add this change. The right thing to do is sort of this solution to
use the routing http://www.ssi.bg/~ja/#rtlsrc but this is a dream,
it is one of the kernel changes I'm talking about for some time.
I can say that policy based routing is simply not supported reliably
by netfilter NAT (SNAT, MASQUERADE). Or as alternative we can add
per-connection routing cache entry (just like TCP does) for inout
direction to replace this rerouting? Such route cache entry is needed
for both directions if we move one day to pre_routing, but I have to
refresh my memory in the weekend with all possible problems related
to such move.
- about 'h.th->syn && !h.th->ack': it can not go in, can you live
without it? It breaks persistent LVS-DR with active ftp because
ip_vs_in can create connections for SYN+ACK packets. Also we have
to be sure that such traffic works reliably with stateful inspection.
- where are the checks 'if (i_am_working_with_LVS_NAT) then WORK' ?
We still do not support this feature for all other forwarding
methods.
- how can we isolate the FTP changes and to make them useful for
other apps?
- make your changes against the tarball, not against patched kernel
> environment, but I'm happy to answer questions as best I can if somebody
> wants to take on the job. If another couple of kernel or LVS releases
> go by without updating the code, it'll become much more difficult to do,
I think, it has been always difficult to incorporate this
feature. Do you have the feeling that we can:
- add config option
- sync it with latest kernels and IPVS
- separate the changes in functions and to ifdef their callings
- try to support it for other forwarding methods (as bonus)
It is assumed that in the current situation the users of
this feature have to stick with the double conntracking.
> and in all probability the functionality will be lost. I think that
> would be a shame, not just because I wrote it :-) but because it seems
> useful and wanted.
>
> Ben.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
