On Thursday 25 November 2010 21:29:30 Richard W.M. Jones wrote: > On Thu, Nov 25, 2010 at 05:24:37PM +0100, Olaf Kirch wrote: > > You may ask, don't we have enough of those already? Don't we have > > NetworkManager, connman, netcf, and a few more? > > Indeed ... You don't explain how it's better than netcf. That's because I'm not a huge fan of introducing my code by dissing other people's projects :-) Okay, so here's where I see the significant differences netcf, from what I have seen so far, converts between sysconfig files and XML using a combination of augeas and XSLT. To bring up and shut down interfaces, it continues to rely on ifup/ifdown scripts. Is that an accurate description? This has a number of problems, I believe 1. ifcfg files are dead First and foremost, ifup/ifdown and the shell scripts that do the dirty work in the background do not scale very well, and I believe as an architecture they've reached their best before date. It gets increasingly hard to represent complex topologies in sysconfig files. Setups like bridges on top of bonding devices on top of VLANs tend to result in rather messy ifcfg files to begin with - and I would guess that was one of the main motivations for creating netcf, and representing network configuration using a hierarchical, extensible syntax such as XML. I think we need to take this a step further, though. Converting the structured configuration data (be it XML or something else, I couldn't care less) to ifcfg files and then invoke the same old messy ifup is not going to work. It's a convenience to those people writing configuration front-ends, but it doesn't do anything to make things work better. Thus, I believe we need to take out the ifcfg format in the long run, and take the structured configuration data all the way to the actual system calls that set up the interface. And that is what wicked does. At the system end of things, wicked doesn't call ip or route or ethtool or vconfig; for all its configuration requirements it talks to the kernel directly. The only concession wicked makes to the "old school" ifcfg files is that it still supports them as one choice of where configuration data can be kept. That's because we have system management tools that mess with these files today, and you probably can't rewrite these all at once. But wicked doesn't *require* ifcfg files. You can easily configure it to store all network configuration in XML files (or any other structured format), and it will just continue to work. (BTW if you look into the source code, you'll find a file named netcf.c which tries to provide a shim layer that translates netcf API calls to wicked's REST API - more of a case study than a complete shim though :-) 2. Why a daemon, not a library The first reason to do this is pretty simple; hotplugging. Traditional ifup doesn't handle this at all; you need to rely on separate services like ifplugd or NetworkManager. But it actually goes beyond that. You may actually want to do more things in response to network events than just hotplug an interface. It can be simple things like, starting a dhcp6 client when we see a Managed/Other flag in a router advertisement. Or consider the usual fun to be had when you need to juggle the information obtained from DHCP running on several interfaces. You get DNS information from two DHCP servers and maybe on PPP uplink - does one of them take precedence? Or should you merge them? What do you restore when one interface goes down? How does that relate to information obtained from iBFT? Try to handle that in shell code, and you'll need a lot of aspirin. (To be honest here; wicked cannot do all of that yet, but it is getting close). So, what I wanted to create with wicked was a network configuration facility that allows to integrate different aspects more closely than what is possible if things live in lots of different applications that were never designed to interact very closely. 3. Why not NetworkManager? On the other hand, there's NetworkManager (and I'm getting to this point because Pete Zaitcev brought this up). Right now, NetworkManager doesn't handle bridges, bonds, infiniband, token ring - that's why I say it's a bit desktopish, the server environment simply has never been the focus of NetworkManager's development. Also, it links against a somewhat longish lists of fairly heavy-weight libraries (including nspr), and requires dbus - all of which make it pretty much impossible to use in initrd or an environment where space is a premium. Olaf -- Neo didn't bring down the Matrix. SOA did. (soafacts.com) -------------------------------------------- Olaf Kirch - Director Server (okir@xxxxxxxxxx) SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
