GSoC 2008: netconf suggesion

[martin f krafft]

Hi Andreas,

thank you for your interest in netconf, and I hope you will apply
for GSoC sponsorship to work on the programme. I am looking forward
to your application.

also sprach Andreas Louca <alouca at gmail.com> [2008.03.22.0053 +0100]:
> After reviewing the current code a bit, I've noticed that the
> current functionality is a bit hardcoded. I am purposing that the
> netconf is converted to a network configuration framework, which
> would support multiple plugins to do the configuration and an
> interface side which the UI programs can interact and push
> requests to the system.

In general, any such effort is worthwhile, and I agree with you that
a framework-based approach with plugins is the way to go. As Bas
pointed out in his reply, one of the reasons why netconf doesn't do
that yet is because I am trying to make things work first. It is to
be assumed that the code will have to be rewritten anyway, at least
when we port it to C/C++, but for now, I think the main goal should
be to get a working version which we can then use to experiment. At
this stage of the project, I'd prefer to keep things simple and not
lose any time in implementing what we think is the right way to do
it, because we might find out that the requirements are not what we
thought initially.

All this said, if you take a closer look at the code, you'll notice
that DHCP and ENI and the like are already sort of like plugins.
Their loading is hardcoded for now, but that's the least of our
concerns. The important point is that the core doesn't know about
any events, it just reads data from file descriptors and reacts by
dispatching them to the registered handlers.

> This would allow netconf to have a cleaner structure, with
> a refined API for plugins and UI configuration programs.

I don't think netconf should have an API for UI configuration
programmes, but enforce the use of the control socket, or a dbus
adapter (which also uses the control socket).

> After defining API interfaces and completing the basic framework,
> I would proceed to complete roadmap targets, as defined in the
> roadmap for version 1.0
> (http://git.debian.org/?p=netconf/netconf.git;a=blob;f=doc/roadmap-1.0.txt;hb=HEAD).

I don't want to discourage you, but please keep in mind that the
primary goal of this project at this stage is to implement the
features needed for 1.0, so that we can provide 1.0 as part of
Debian lenny in August.

> Framework initialization
> Scan for plugins
> Plugins initialization

This is all well and can be trivially added to the existing code,
I think. I don't think it needs to happen right now.

> Register its function (eg. can configure IP interfaces)
> Register events it can generate to the event engine (eg. ethernet
> disconnected), so UI utilities can hook to them

Initially, netconf was event-based and it had a class Event with
a parameter "type", and plugins would register their events and
event handlers. However, it turned out that all I ever did was read
data from file descriptors and create events, stuff them in a queue
and then process them by the main loop. Thus, I cut out the middle
man and just made the main loop process the file descriptors
directly. The effect was the same with a little less abstraction,
but so far I have not identified any shortcomings with this
approach.

> Register the architecture(s) that the plugin supports (Linux, FreeBSD
> etc), which would also determine if the plugin is enabled or not

I don't see the benefit of letting netconf know the architecture and
act differently on different platforms. Instead, I'd like it to
implement handle the functionality we require of netconf, and push
the task of implementing and getting it to work on different
platforms to the maintainers/users of these platforms. In order to
make this easier, I want to keep all architecture-dependent stuff in
scripts/plugins (which could be C programmes using syscalls). This
is the same approach as taken by the ISC DHCP client, which is
a standard piece of software these days and works quite well in most
scenarios.

> Hook to the system events, so plugins can propagate those events
> to UI programs, or react in certain cases

I plan to add a netlink reactor, yes. Plus, a dbus adapter might
dispatch "events" via the control socket.

also sprach Bas Wijnen <wijnen at debian.org> [2008.03.22.1131 +0100]:
> Or via any other communication route.  It's a UNIX socket in the
> current implementation, and it will probably stay, but there may
> be additional methods as well (such as web-based), if it's up to
> me. :-)

Ew! :)

> It sounds good to me.  Not that I have any decision-making-powers
> in the project. :-)

Everyone does. I herewith resign from any dictator-like position.
Let's make netconf good, I don't claim I know exactly how to do
that. :)

-- 
 .''`.   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
 
"science without religion is lame,
 religion without science is blind."
                                                    -- albert einstein
-------------- 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/20080323/61b00434/attachment.pgp