question about netconf and GSoC

[Alexey Tarasov]

> One of possible solutions is to make system dependent dictionary
> mapping event to some script and use it like in such pseudocode:
>
> runner = RunnersFactory.createRunner(EVENT_NAME)
 Why not just replace the shell script with a version that uses tools
available on FreeBSD?

It's to make more abstract from event handler implementation. In the
simpliest case (to keep all in scripts, but give opportunity to extend event
handler types in future) it's possible to make dictionary, used by this
factory with EVENT_NAME => some_os_system/event_name.sh. for Linux it will
be linux/event_name.sh, for FreeBSD freebsd/event_name.sh and etc. So you
may still work with shell scripts, but it is hided from higher level of
code. If you add in runtime want to change script, then you just modify
dictionary (via control socket or somehow else) and newly created handlers
will automatically use new script, without changing of core source code.

> I want to keep netconf as simple as possible and, in true Unix
> fashion, it should let other programmes what they do.

Ok, I've understood your point.

 > = 4 =
> May be policy and security related problems. IMHO, syntax like
> squid acls is good enough. E.g.

The policy also needs to be able to encode flow, like what is to
 happen when DHCP fails to get a lease.

by policy here, I've meant security policy.

>> = 5 =
> This is more or less what I want, yes: the policy tells you which
> approach to take when the previous one failed. Approaches are
> implemented by modules.

What do you think about some kind of semi-automatically choosen flow?

Every module (event handler) has definition (category, e.g. "DHCP client"
and priority). Definition may:

   1.

   be given in "flow policy" file
   2.

   category taken from module via call to some known function, priorities
   are taken from flow policy file.

There may be dispatcher, which has info about all defined categories checks
result of event handling and chooses from available modules, depending on
needed category and priorities of modules.


>> = 7 =
> ACPI handlers should talk to netconf vie the control socket; they're
> not part of netconf, and netconf should not even know about ACPI.
I'm not sure, if netconf has now event kind of "save current state". As
netconf is aimed to configure network, ACPI handling scripts must only ask
to save interfaces state, renew state after powerstate change and etc. I've
meant such kinds of events as it a little bit differs [or may differ] from
initial configuration.


> Thanks for your interest. Sorry if my answers are a bit short, I am
> too tired...

Thanks for comments.

---
Best regards,
Alexey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20080315/241995a9/attachment.htm