Re: ifupdown-bonding package
Hello,
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:
<http://www.debian.org/devel/join/newmaint>
<http://www.debian.org/devel/>
<https://nm.debian.org/>
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
file.
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 :-)
Jerome
Reply to: