Em 09-06-2014 12:03, sven falempin escreveu:
> ifstated is a cool FSM emgine for handling the carp problems,
> for more complex need , instead of hacking this not complete FSM engine,
> i would just used another software.
>
> The last time, i just use plain perl script, because it was convenient
> and easy to read,
> using a true FSM design was just making the logic more complex.
>
> IMHO the way to improve ifstated is to fork it so it becomes a full FSM
> engine,
> with transition and node definition, and each part using perl or ksh code.
>
> node 1 {
> entry : {perl code}
> leaving: {ksh code}
> eventX : node 2
> }
>
> The all work would be on the eventX , how to create one in a cron like
> process, how to bind the superb kqueue, and
> how to get notified from the network states change.
>
> Now , if ifstated is not able to handle what it was design for (CARP)
> i guess it should be fixed.
It definitively does what it was designed for. But I believe that these
improvements would also benefit carp only deployments. If a carp node is
failing more than N times in the last few minutes, it might be a good
idea to completely fail it over and enter on a different state. I use my
ifstated setup for both carp and isp link failure detection. I took a
look at ifstated code and I've been fiddling with it for a little time
now. I believe that the counter based approach is easy to implement with
less disruption. The time based one is more difficult. As I mentioned,
I've been using ifstated for years now (10+ IIRC). And more often than
not, isp links behave erratic. Carp can also have problems if the
network hardware underneath it does not behave correctly. I don't
believe that all of these situations can be solved even with a true FSM.
That's why I'm proposing these improvements. But, I wanted to discuss
with you guys here on tech@ first. Perhaps something entirely different
needs to be done.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
