On Mon, Jun 9, 2014 at 10:38 AM, Giancarlo Razzolini
<grazzol...@gmail.com> wrote:
> Hi tech,
>
>     I've been using ifstated for years now for failover my links and
> I've developed quite some tools on top of it. But, I've recently reached
> a cornerstone. I've developed a series of scripts that are called with
> the run argument on the init of each state that perform a series of
> tasks. One of these tasks is to write to a database (currently sqlite)
> and based on the last state changes, perform different actions. But,
> since I can't talk directly to the ifstated daemon, I have a delay since
> I can affect any state change on it.
>
>     So, I've been planning on improving ifstated itself, for it to be
> able to keep track of state changes and the time they happened, so it
> can be able to improve it's decision making capabilities in the sense
> that it can perform state changes based on previous states changes. Not
> just on external commands results or interface statuses. You could say
> something like this:
>
>      set-state X
>         if ! previous_state Y
>
>     More to that, it could be also based on a more simplistic approach,
> using counters. With the possibility of zeroing the counters from
> ifstated.conf based on conditions. Or both, time and counters. So one
> could change to a different state if one of the links is flapping
> between states. I know this makes it not a pure machine state, but I
> believe that the improvements can be worth the change. What you guys think?
>
> Cheers,
>
> --
> Giancarlo Razzolini
> GPG: 4096R/77B981BC
>

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.

-- 
---------------------------------------------------------------------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\

Reply via email to