|
Hi Wensong,
o What about inclusion into mainline? ;)
I would really like to see that it is included, but it is not me to make
the decision. ;)
Ok, let me ask differently: Are you going to ask DaveM and/or Alexey or
shall I prepare such email?
After we release ipvs-1.1.7, we will ask DaveM and/or Alexey for the
possible inclusion together, OK?
Very good, yes :).
Hey, if you're already in a mood of accepting so many changes what do
you think if we just include the whole per RS threshold limitation
backport to 2.4.x once it's tested enough?
For that one I also have a question: You probably remember that I used
to quiesce all RS when upper threshold was reached in 2.2.x days. My
user space app could then determine with a simple awk if all RS of a
service template are quiesced and thus if the whole service would be
overloaded. It would then invoke a session overload page on localhost
via local route forward. And if the RS service was not reachable anymore
through one of the various healthchecks the user space app would take it
out and in case of a complete outtake of all RS on a service template
invoke a page of last resort indicating that the service was currently down.
The page of last resort takes precedence over the session overload page
unless persistency is enabled for the latter (obviously). What's
important to realise is that I did a distinct separation between a
session overload and a service takeout!
Now with the new implementation of the per RS threshold limitation I do
not get any indication in user space which shows me the status, as
internally only the IP_VS_DEST_F_OVERLOAD flag is set and if it is set,
the scheduler doesn't pick this dest. Which is basically the same, as
seen from user space, like taking the service out with ipvsadm -d ... .
How do you think could I solve this problem of mine?
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
|
