GSoC 2008: netconf suggesion

Thu Mar 27 09:38:26 UTC 2008

Hello!

Thank you all for your comments. I will proceed and submit an
application for netconf today, taking in mind this discussion on my
project description.

Please see my replies inline.

On Sun, Mar 23, 2008 at 5:19 PM, martin f krafft <madduck at debian.org> wrote:
> 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.

I don't think its gonna take a long time to form a framework in
Python. It would also provide a guideline for APIs when the port for
C/C++ is due. However, if the project is just for a proof-of-concept,
I agree that this can be omitted.

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

By UI programs I meant for every program that needed to change any
configuration, either via dbus or a socket. I think dbus is the way to
go.

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

Understood.

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

Agreed.

>
>
>  > 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! :)
Why not?:P

>
>
>  > 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
>
> -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.6 (GNU/Linux)
>
>  iD8DBQFH5nUTIgvIgzMMSnURAoDmAKCM89F7sZ3kEE8X4r6zz4x/UqDUIwCeP9d6
>  df2SkHnyuvsZFhfIpe0+B4A=
>  =DOE5
>  -----END PGP SIGNATURE-----
>
> _______________________________________________
>  netconf-devel mailing list
>  netconf-devel at lists.alioth.debian.org
>  http://lists.alioth.debian.org/mailman/listinfo/netconf-devel
>