GSoC 2008: netconf suggesion

[Bas Wijnen]

Hi,

On Fri, Mar 21, 2008 at 11:53:39PM +0000, Andreas Louca wrote:
> After reviewing the current code a bit, I've noticed that the current
> functionality is a bit hardcoded.

What I've heard, the hardcoded parts are to be replaced, they're just an
easy way to get things working initially.

> 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.
> 
> This would allow netconf to have a cleaner structure, with a refined
> API for plugins and UI configuration programs.

That sounds like what was planned. :-)

> A typical startup sequence would be like this:
> 
> Framework initialization
> Scan for plugins

I suppose this is only for the initial plugins?  At least IMO, it should
be possible to add (and remove) plugins while the system is running as
well.

> Plugins initialization
> 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

I understand that you want the server to not know a full list of events,
so new plugins and new UIs can invent their own and use them without
needing to update the server?  This sounds like a good idea.

> Register the architecture(s) that the plugin supports (Linux, FreeBSD
> etc),

I don't like this.  IMO, the framework should be as platform-independent
as possible.  The default should be that everything works everywhere.
In particular, adding a new architecture should not include adding it to
all plugins as "this one works here, too".

In exceptional cases it may happen that a plugin doesn't work on some
system, or even only works on one system.  For those cases, it is good
to not show up on systems where it isn't supported.  But the default
should be that things must work everywhere, and people writing plugins
must not get the idea that it's acceptable to write unportable code.

> which would also determine if the plugin is enabled or not Hook to the
> system events, so plugins can propagate those events to UI programs,
> or react in certain cases

This response sounds good, but it should be a response to the user
enabling (or disabling) certain plugins, not to the plugin being broken.

> Initialize framework interface, and start accepting requests


> A typical configuration request sequence would be like this:
> 
> UI program requests to run DHCP on an ethernet interface (configure IP
> interface, DHCP)
> Sends a request via a UNIX socket to netconf

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. :-)

> netconf checks the list of registered plugins that support configuring
> an IP interface using DHCP
> Adds the request on a work queue, and the queue manager calls the
> plugin with the parameters that the UI program passed.
> Plugin would performs the necessary actions requested, triggering
> events as necessary (ie: DHCP sending broadcast etc), which would
> allow the UI program to update the interface.

For this reason, it makes sense that the UI gets personal feedback that
these events happen because of its request.  If the UI wants to say
"Done foo, starting with bar", it is useful if the UI doesn't actually
need to know what steps are expected to be taken.  So it can just echo
whatever the plugin says to the user.  For this, it is important that
the feedback in response to the request is not the same as the
notification of events in general.

> After performing the actions the plugin sends a reply, depending on
> the results (failed or  success with IP xxx.xxx.xxx.xxx etc).
> 
> I hope I have demonstrated my idea adequate and I am walking on the
> correct path.

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

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/20080322/6573610c/attachment.pgp