Hello all.
I am planning some "revamping" of wackamole code on the functionality
side. Wackamole is super-cool technology, but lacks a few things that
are really necessary to use it in enterprise environments. I would like
to solicit items for the TODO list so that I can incorporate as many
solutions into a single design and implementation cycle.
If you send a message here that says:
(1) Wackamole is cool :-)
(2) It almost useful in the environment A.
(3) I can't get it to work because it is lacking B.
(4) Suggest a solution with or without implementation details C.
Please be descriptive about A, B and C.
To start:
(1) wackamole failing over multihomes machines is awkward or
impossible. Say I have to machines:
10.1.1.2 and 10.1.1.3. At most one machine should have "gateway" IPs
for other machines. (e.g. 10.1.1.1, 192.168.0.1, 192.168.10.1).
In a situation where these machines need to route traffic, it is an all
or nothing situation. It needs all the appropriate IPs or asymmetric
routing will take place and firewall rules are harder to execute.
A solution would be to specifiv "VIPs" as the "unit" that wackamole
manages. These VIPs can be sets of IPs instead of just a single IP as
it is now.
(2) wackamole doesn't handle non-contiguous VIPs.
a set of wackamole instances cannot manage an arbitrary set of IPs.
They must be continuous.
A solution would be to specify these as individual VIPs (see item 1).
(3) the configuration file needs to be more complicated to support (1)
and (2)
this is difficult because its parsing is not done with a programmable
lexer/parser.
A solution would be to rewrite the configuration file parsing to use
lex/yacc.
(4) I can "almost" use wackamole to cover my web servers in a DNS RR set
up.
It doesn't completely work because it only handles failure of the
machine or -- spread or wackamole which never happens :-)
A solution would be to add service level checks to wackamole so that
wackamole can either actively check to see if a service is alive and
well or passively be notified that a service has failed (or is being
taken down).
Please feel free to add more here!
--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
I am planning some "revamping" of wackamole code on the functionality
side. Wackamole is super-cool technology, but lacks a few things that
are really necessary to use it in enterprise environments. I would like
to solicit items for the TODO list so that I can incorporate as many
solutions into a single design and implementation cycle.
If you send a message here that says:
(1) Wackamole is cool :-)
(2) It almost useful in the environment A.
(3) I can't get it to work because it is lacking B.
(4) Suggest a solution with or without implementation details C.
Please be descriptive about A, B and C.
To start:
(1) wackamole failing over multihomes machines is awkward or
impossible. Say I have to machines:
10.1.1.2 and 10.1.1.3. At most one machine should have "gateway" IPs
for other machines. (e.g. 10.1.1.1, 192.168.0.1, 192.168.10.1).
In a situation where these machines need to route traffic, it is an all
or nothing situation. It needs all the appropriate IPs or asymmetric
routing will take place and firewall rules are harder to execute.
A solution would be to specifiv "VIPs" as the "unit" that wackamole
manages. These VIPs can be sets of IPs instead of just a single IP as
it is now.
(2) wackamole doesn't handle non-contiguous VIPs.
a set of wackamole instances cannot manage an arbitrary set of IPs.
They must be continuous.
A solution would be to specify these as individual VIPs (see item 1).
(3) the configuration file needs to be more complicated to support (1)
and (2)
this is difficult because its parsing is not done with a programmable
lexer/parser.
A solution would be to rewrite the configuration file parsing to use
lex/yacc.
(4) I can "almost" use wackamole to cover my web servers in a DNS RR set
up.
It doesn't completely work because it only handles failure of the
machine or -- spread or wackamole which never happens :-)
A solution would be to add service level checks to wackamole so that
wackamole can either actively check to see if a service is alive and
well or passively be notified that a service has failed (or is being
taken down).
Please feel free to add more here!
--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7