design decision: event sources

[martin f krafft]

Folks,

I have to make a design decision — in fact, I have been putting it
off for the past 24 hours because I cannot really make up my mind.
Thus I turn to you with the hope for some input.

While netconf is an event-based system, I wonder whether I am
overusing the event queue. I conceptualised netconf such that
configuration would happen in response to events. So whether it
determined from a file in /etc that eth0 should get IP 1.2.3.4, or
the DHCP server told the client that its new IP should be 1.2.3.4,
netconf would actually react to an IPADDR event being raised.

Thus, invoking /sbin/ifup would cause a CTLSOCK_IFUP event, which
would create an IFUP event, which would then create a series of
IPADDR, IPROUTE, DNS_NAMESERVER, etc. events. Similarly, dhclient
would issue IPADDR/IPROUTE/etc. events in response to DHCP events.

I now wonder whether these "second-level" events are at all needed.
Please read on.

Over the past week, I simplified netconf quite a bit. It is now
still event-based, and IFUP still exists, but its event handler now
hands off work to an interface handler (e.g. ifaces/eni/handler.py)
and passes a manipulation policy (e.g. ifaces/manip/logonly.py - the
only one right now) along. The idea is that the interface handler
delegates the actual work to the manipulation policy, such that it's
trivial to put e.g. a log-only policy in place to be able to see
what netconf would be doing without it actually manipulating the
interface.

So after the IFUP event handler asks e.g. the "eni"-handler to
configure eth0 with the IfaceManipPlain manipulation policy, the
eni-handler determines that eth0 should get the static address
1.2.3.4 and calls IfaceManipPlain.add_ip_address('eth0', '1.2.3.4').

What should IfaceManipPlain.add_ip_address do now? For some reason,
I still want it to raise an IPADDR event and have the IPADDR event
handler take over, which corresponds to my initial idea for netconf,
but I cannot remember anymore why I used events at this level, nor
can I now see a benefit.

Events and event handlers are great, especially in asynchronous
processing. However, an interface manipulator, such as
IfaceManipPlain.add_ip_address would basically be a synchronous
action. Instead of it raising an event and letting the event handler
invoke the method to do the work on the interface, why not let the
interface manipulator invoke the method directly?

What benefit could I get from inserting the event queue between
interface handlers and the actual manipulation methods?

I want netconf to be a "closed-loop system" because I was fed up by
ifupdown and dhclient not talking to each other. I want netconf to
know when dhclient does something, and be able to react to it. If
I let the interface handler control dhclient and call the
manipulation policy methods to synchronously control the interface,
then this happens in a thread somewhat "next to" the netconf core.
I can then ensure that there won't be dhclient processes left over
for interfaces that don't exist, but am I giving up control if
I don't go via the event queue?

I hope this mail is comprehensible. I appreciate any input, or maybe
someone has the time to come to #netconf/irc.debian.org to discuss
this a bit. I will be travelling tomorrow (Tuesday, 15 Jan), but
shall be available the following days (or tonight).

Cheers,

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"solange man nicht die moral des christentums
 als kapitalverbrechen am leben empfindet,
 haben dessen verteidiger gutes spiel."
                                                 - friedrich nietzsche
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20080114/b4ebc071/attachment.pgp