[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ifupdown-bonding package


First of all, I'd like to thank you for taking the time to read my email an answer it.

Loïc Minier wrote:

Documentation on joining the project or helping the project is
available at:

I think it should answer your technical questions, and clear up
anything regarding current procedures.
Yes, as I stated in my original post I already started reading newmaint and policy, and I joined my ml so I can get real-world examples of how things are done and and general feeling about the right attitude (which I may not have yet :-).

Please find below the short README I wrote (no manpage yet ... will make
one if this is of interest).

Since I use vlan over bonding and had some trouble myself, I read the
README as a whole and added comments below.  In general, I think your
approach is oriented in "let's document how to workaround bugs and make
it work", while a better approach might be "let's understand and fix
each bug to let that work flawlessly".
Well, I am a bit surprised by the way you see it. Could you be more specific ?
The main goals of these scripts were :
- provide a way to describe bonding interfaces in network/interfaces without the burden of repeating the same ifup/ifdown definitions. - provide a way to simplify the process by setting defaults enabling fast testing/setting up. Of course I realise that these defaults cannot be universal, that is the reason why I suggested the possibility to override them in network/options. You tell that this file is deprecated, so I should find some other way to do it, but the spirit remains the same : centralise some defaults, render the interface definition less verbose, lighter. - allow one to configure easily the bonding module from inside the interface definition

I feel that those 3 goals are fixes to problems I have encountered myself.
As for my future goals (to be implemented, but I'm working on it and have something soon) :

- Add logic to check VLANs are up only AFTER the main bond interface is up and attached to at least one slave (in order to ensure no mac address issues will occur) - Add logic to configure arp monitoring using the default gw / resolvconf hooks / whaterver makes sense (suggestions welcome) - Add logic to check that slave interfaces do not have IPs configured nor routes (in order to prevent conflicts) befor the bond is started - Add logic to detect which modules are used by the slave interfaces and eventually unload themfirst and reload them after the bonding module (so that SNMP if queries will report the bond as the "owner" of its IP address). I realise that this impacts heavily the logic dictated by configuring modules in modprobe.conf / modprobe.d, maybe there is something that could be done with an external tool handling this (and storing configuration via debconf ?) ? What would be the "debian way" ? - Add logic to check there is no IP attached to an underlying bond interface before bringing up VLANs.

All that to say that my goal is to provide code to solve issues, not only document them. However, at some point, I hacked down the README as much as a reminder of items to investigate than documentation for people willing to use the embryo of features already coded.

However, I'm a lost, because in order to acheive all those "automatic handling of all VLANs+bonding issues" it seems that a lot more changes would be required to the network modules handling + ifupdown architecture than just a few hooks.

Again, some insight on the "debian way" would be greatly appreciated. One one side, I like the DIY approach of the interfaces file, with manually configuring ifup/preup/etc. stanzas. On the other hand, the network/*.d system DOES exists, but seems underused ... so far I found resolvconf, vlan and the not-yet-fully-understood-by-me ifupdown-scripts-zg2 package (if someone could elaborate on this one, its goals, how "debianish" it is, I am willing to offer a full round of beer to anyone willing to come to Paris to drink with me ! ;-).

ifupdown-bonding README
This is version 0.1 of the package, as of 10/17/2005.
This package contains hooks for ifupdown in order to add bonding and
VLAN for bonding syntax to /etc/network/interfaces.

In general, packages don't hold very small things, especially they
don't hold a couple of scripts and documentation to enhance another
package;  instead, you can file a request against the package you
Agreed ! :-)
As stated (or implied ? I should be more clear ... ) in my previous post, at least the part on "automagic" VLANs should belong to the VLAN package. But this is a quick hack, not even a real package yet, intended to be able to "patch"sarge in production with minimum fuss.

enhance (in this case it could be "ifupdown" or "vlan") to include your
documentation and scripts.  Also, package version and latest date is
already encoded in the changelog of the package, and duplicating it
means more work.  :)
Sure. My bad. c.f. above comment about roughness of the current assembly :-)
However, I frequently encountered docs in /usr/share/doc/* where having a timestamp would have been a good thing (tm) ! I have noticed that the docs there are frequently of interest but slightly out-of-date. Having a timestampg here is something that could lead to render old but still relevant docs mroe usefull. A good example for my case is stating that all options "currently" supported by the bonding module are handled. But I agree this one might be a bad example as the version of the kernel/module should suffice.

While I am at it, my scripts currently require bash (shopts extglod and such) to work. Is that something acceptable in network scripts ?

[ long list of should and shouldn't ]

=> IMO, it's too heavy to list everything you should and shouldn't do.
Just give a working example people should follow, if they don't, it
won't work.
OK, I agree this should belong to some sort of "VLAN+bonding" HOWTO. And in fact I believe this is already documented somewhere, but scattered in mupliple places.

- If you want to override default values passed to the bonding modules
without specifying those
values in all your interface definitions, use the /etc/network/options

That file is deprecated in recent netbase packages.
Where can I find documentation about the reason why, the new policy, and the direction behind it ?

[ snip long example of a sample bond device ]
iface bond0 inet manual
      slaves eth1 eth2

Good.  Would be nice to include in the interfaces manual page, or along
the ifenslave packages.
I agree. But what about a more complete bonding+vlan handling (see above) ? Would that still belong to individual packages providing the underlying feature (ifenslave) ? Or should scattering it should be avoided in order to maintain a coherent whole, more easily maintainable ?

auto bond0.50
iface bond0.50 inet static

auto bond0.60
iface bond0.60 inet static

Completely natural examples, that are specific to using bonding + vlan,
I'd ship these in the same documentation.

I'd add to this that currently one needs to "configure" the
/etc/network/if-pre-up.d/vlan script to accept setting vlans on bonding
interfaces by changing "eth*.*" in "eth*.*|bond*.*".
Well, I've already written specific scripts for that, but as stated before, I suppose this should go into the vlan package.

I'm personally using my vlaned-bonding-interfaces in bridges, and use
the following stanza to bring the interface up:

   auto bond1.40
   iface bond1.40 inet manual
       up ifconfig $IFACE up
       down ifconfig $IFACE down
Well, that's what I used to do. Plus lines for ifenslave and ifenslave -d. Plus configuration of the modules in a separated file, not easily changeable on-the-fly (manually unload/reload module invoved, again scattering configuration semantically linked all around the place). And all the various checks I mentionned earlier would only be realistically implemented with a centralised up/down code.

My feeling is that the current ifenslave packages "feel" like Debian
already, but do not offer advanced options, and the vlan packages
doesn't feel like Debian and tried encoding information in the
interface name instead of defining it's keywords as other packages do.
Well, I have always felt that the debian way was not to change the semantics of the upstream software. And automagic interface naming IS part of the vconfig semantics, see the set_name_type options. However, in this particular case, I share part of the same feeling : I would prefer not have the name of the interface carry any semantic at all. This can be misleading. The reason I mimicked this behavior was mostly to satisfy my crave for consistency, added to the fact that the vlan package being already into debian, I took for granted that this is the right way to do it :-)

But on the topic of adding "advanced options", I tend to strongly disagree with you, but this requires some explanations :

- I like uncluttered configuration files, but with as few levels of abstraction needed. So I agree that most "automagic" stuff are a pain by nature, because they hide functionnality and often restrict usage to narrow cases. - However, in a production environment, what I need is : reliability, simplicity of deployement, minimal risk of error on reconfiguration, ease to reproduce configuration. Given those requirements, current bonding + VLAN + bridge (I use Xen and other bridging stuff too) _IS_ bloated. Pieces everywhere. Even scripts (I use FAI) to autoinstall/upgrade require to crosscheck several places/files, increasing the risks for error. When modifying a configuration, I need a long checklist to do it right on first try, and even so, I sometimes forget/overlook something. Not because I am not tech-savvy enough or attentive. But merely because the human brain will fail to accomplish complex tasks on a regular basis in a manner directly proportionnal to the quantity of information to be manipulated. Reducing that quantity of information/checks to make both makes automatic scripts simpler (and I only trust automatic deployment script when they are OBVIOUS) and manual configuration verification/modification easier and _more reliable_. - On the topic of network configuration, I have the feeling that thoses criteria are met by having :
 . a centralized place to handle all interfaces configuration
. a centralized place to handle default options ( was network/options, I don't know anymore) . checks for coherency of the configuration ( very similar to "robustness" of code when programming, mostly error checking and handling)
 . a predictable behavior (ordering module load falls into that category)
. if a centralized placed cannot be offered, then there must be a way to provide a unified "view" (in the database sense) of the various elements. This could be acheived through a configuration program. But I do not like the level of complexity this adds to the system, plus the fact that you always have conflicts between automatic v.s. manual edition of the configuration files.

What do you think ?
Can anyone share pointers with me as of what is the "debian way" ? Or at least what are the conflicting views on those matters ?

I am very open to rethink completely the way I currently imagine how things can be done, and also ready to puit coding and documentation efforts into this. Like most people, I am willing to do it to "Scratch an itch", that itch being "Currently, there is nothing better than debian for my needs - robustness, good policy, coherency, "unbloatness". However, those vertues seem to be absent from an area I need to be solid ASAP : fast deployement, fast reconfiguration, all using failover under VLAN under bridges, custom configuration files, on different but similar hardware.".

I currently am trying to use FAI because preseeding in d-i is not mature yet for the functionnalities I need, and also because d-i cannot pursue the task of managing configuration (it being network config but also soft RAID + LVM) after the install on several servers. This might seems a bit off-topic, but in order to be able to manage my network and servers globally (gold hosts, CVS configs), I need the configuration pieces to be more "intelligent", to lighten up the burden of the configuration management system whose inherent complexity is more than enough to handle without added complexity due to hard-to-manage (in the reliability/simplicity/deployment-friendly/human-factors wareness way) configurations.

I hope my prose was not too much to read, I am afraid I become pretty verbose when it comes to subjects I take to heart :-)

Have a good day :-)


Reply to: