question about netconf and GSoC.

Wed Mar 12 13:49:40 UTC 2008

Hello,

On Wed, Mar 12, 2008 at 11:15:57PM +1000, Alexey Tarasov wrote:
> I've found that netconf project will be in the GSoC'2008 and want discuss
> some details, cause it seems interesting for me.

That's nice to hear.  Note that "will be" is not at all sure at this
moment.  It's just a proposal AFAIK.

> I've some thoughts, but I need confirmation that I'm thinking in
> correct or incorrect way. Below are some areas, that I think, may be
> improved.

I'm planning to look at the code, but haven't yet, so I can't answer
everything, but I'll give my opinion on some points.  Anyone should
correct me when I'm talking nonsense. :-)

> = 1 =
> I want port netconf to FreeBSD (cause I like FreeBSD last years more than
> Linux). For this purpose some replacement is needed, cause netconf deeply
> relies on shell scripts, that utilize iproute2.

Iproute2 provides an interface to the kernel.  AFAIK, this interface is
not kernel-specific and could in principle be implemented on any other
system with networking support.

If this is correct, then IMO netconf should just continue to use those
tools.  If things can't work on FreeBSD that way, the bug is with
iproute2 not being available there, not with netconf using it.

> Actually that also prevents from porting netconf to very old Linux
> distributions also (I don't know if they are still used widely enough,
> but I've seen some of them still working).

I don't have a problem with requiring people to use a reasonable new
kernel.  Getting iproute2 to work on an old distribution with a new
kernel should be no problem.

> The main idea is go away from running creation of objects like:
> 
> runner = methods.Runner(somescript)
> 
> 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)
> 
> where RunnersFactory is object with such system dependent dictionary or may
> create Runners with other than Runner(script_string) constructors.

I don't know enough about the internals to comment much on this.  In
principle, passing events instead of scripts sounds good to me, but
doing different things on different platforms should be avoided whenever
possible IMO.

> Other one opportunity - forget about scripts and use C module, which
> executes system calls. There are not so many network related events, so one
> solid network related module may handle all of them by cost of a little bit
> harder extensibility.

And more work.  Those script tools already exist, the module still needs
to be written.

> = 3 =
> I've looked through sources and found that IP class uses only IPv4. it's
> better to revise all related modules and provide partial support of IPv6 at
> least.

I agree.

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

IMO the policy should be very flexible, but very simple.  That means
something like you propose would be one option, but there should also be
a way to use user-provided scripts to decide what is allowed.

> = 5 =
> Some kind of related plugins. E.g. There is some task. Try first plugin,
> then next if first failed. This may help use IPv6 (fall over to IPv4) and
> some other fall overs from protocol to protocol. If plugin knows about
> plugin to failover t, it's simple (just make event to handle by other
> plugin). But if plugin has no such knowledge, some workaround is needed, e.g.
> configuration files with list of plugins to use sequentially.

This is conceptually a hard problem.  It would be nice if the plugins
don't need to know about each other's existance, so you would need to
use the list approach.  However, sometimes a plugin may want to say "I
can handle this, but it won't be optimal".  Should it fail or not?

Perhaps it would be best to always ask all plugins and let them say how
good they can handle it.  Filter those numbers through some
user-provided filter (default: don't change), and the highest scoring
plugin will actually handle the event.

> = 6=
> It seems good idea to extract plugins from existing sources and make core
> really small core with a huge amount of plugins, that now are only python
> based only (mainly cause EventHandlers are python based).

Separating plugins from the core is always good IMO.

> That also needs some specification of core <-> plugins data exchange.

And that's one of the reasons that it's good. :-)  It is some work to
specify a good protocol, but the gain is a much more stable system with
less unpredictable behaviour.

> = 7 =
> May be some ACPI related events. Usually (at least in FreeBSD) two scripts
> are used to handle power state changes. So, new events must be implemented,
> that are generated from this scripts. Not only power state change, but
> configuration change (e.g. power for notebook Ethernet NIC is offed by
> switch, driver is loaded, logical interface still exists but not works
> really)

I think Martin talked about this sort of thing at FOSDEM.  What he said
was basically that we don't want to hack around bugs.  I agree with
that.  (This is related to the iproute2 thing as well.)

I think it's good to handle events like "go to sleep" and "wake up",
which can come in response to ACPI events.  However, hacking around
hardware bugs should happen as close to the hardware as possible, which
(almost?) always means not in netconf.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20080312/02495146/attachment.pgp 