General comments.
Jiri Pirko (jpirko(a)redhat.com) said:
example cfg file:
$ cat /etc/sysconfig/network-scripts/ifcfg-teamx1
DEVICE="teamx1"
NM_CONTROLLED="no"
ONBOOT="no"
TYPE="Team"
BOOTPROTO="dhcp"
TEAM_CONFIG='{"runner": "roundrobin", "ports":
["eth1", "eth2"]}'
This is inline JSON, I suppose? It's not really appropriate as something
stuffed in a shell configuration variable. I realize the current bonding
code does a similar hands-off thing with BONDING_OPTS, but that at least is
constrained to simple key-value; embedding JSON (or python, or similar
things) seems a bridge too far; it especially makes the job of machine tools
that may have to parse the configuration messy.
Perhaps options like:
TEAM_OPT_RUNNER=roundrobin
etc.
Reliance on device names in the configuration can be problematic, depending
on how consistently your slave devices are named.
The implication is that team device names are arbitrarily named? That
is not necessarily a problem, just confirming. (Although, sticking to a
naming schema offers a benefit, see below.)
diff --git a/sysconfig/network-scripts/ifdown-eth
b/sysconfig/network-scripts/ifdown-eth
index fcbae80..8fbd0d2 100755
--- a/sysconfig/network-scripts/ifdown-eth
+++ b/sysconfig/network-scripts/ifdown-eth
@@ -133,6 +133,14 @@ if [ -n "${BRIDGE}" ] && [ -x /usr/sbin/brctl ];
then
fi
fi
+if [ "${TYPE}" = "Team" ]; then
+ if [ ! -x /usr/bin/teamd ]; then
+ net_log $"Team support not available: teamd not found"
+ exit 1
+ fi
+ /usr/bin/teamd -k -p /var/run/teamd-${DEVICE}.pid || exit 1
+fi
+
While the check is technically correct, if you've gotten to the point where
you're bringing down a team device while not having /usr/bin/teamd
installed, something has gone pretty wrong somewhere.
+# If the device is a team, create it with teamd, if available.
+if [ "${TYPE}" = "Team" ]; then
+ if [ ! -x /usr/bin/teamd ]; then
+ net_log $"Team support not available: teamd not found"
+ exit 1
+ fi
+ /usr/bin/teamd -g -d -t ${DEVICE} -c "${TEAM_CONFIG}" -p
/var/run/teamd-${DEVICE}.pid || exit 1
+fi
+
Again, passing raw JSON on the commandline seems awfully hackish.
I also note there doesn't seem to be any corresponding provision for
configuration for the slave interfaces. The assumption is that you're
leaving them 'unconfigured'?
Now, to the nitty-gritty:
I really don't like the idea of adding support for more and more device
types to initscripts, especially if it's not yet fully sure what their
long-term future is. For example, we added support for wrapping ipsec-tools
connections in the initscripts, and that's turned out to be a bad idea, yet
we're left with the compat. Furthermore, when they are duplicate device
types (as team interfaces are, with respect to bonding), I don't like
exposing them unless there's a clear plan as to which technology is intended
to be the standard long-term - I'd rather not maintain parallel
infrastructures indefinitely.
So, at this point, I don't think I'll add this. However, it should be pretty
easy to make it work for you. For example, if you declare that all team
devices are named "teamX", then you can create
/etc/sysconfig/network-scripts/ifup-team:
#!/bin/sh
. /etc/init.d/functions
cd /etc/sysconfig/network-scripts
. ./network-functions
[ -f ../network ] && . ../network
CONFIG=${1}
need_config "${CONFIG}"
source_config
if [ "${TYPE}" = "Team" ]; then
if [ ! -x /usr/bin/teamd ]; then
net_log $"Team support not available: teamd not found"
exit 1
fi
/usr/bin/teamd -g -d -t ${DEVICE} -c "${TEAM_CONFIG}" -p
/var/run/teamd-${DEVICE}.pid || exit 1
fi
exec /etc/sysconfig/network-scripts/ifup-eth ${CONFIG} $2
...
And a similar ifdown-team, all packaged with teamd. This allows you to
evolve your configuration & setup as needed without being tied to
initscripts updates, and we can evaluate when to merge things in the future.
If you need it not tied to the device name, it's easy enough to fix
initscripts such that ifup-team is keyed off of TYPE=Team.
Bill