On Wed, 2012-02-01 at 12:52 +0100, Jiri Pirko wrote:
Tue, Jan 31, 2012 at 09:42:22PM CET, notting(a)redhat.com wrote:
>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.
Problem is that team config is hierarchal. Therefore there's no easy way
do map it to simple list. That's why I chose JSON.
The problem is that other tools cannot easily parse this. It also takes
way too much syntax for somethign that's supposed to be human editable.
Just because teamd takes the config in a python/JSON format doesn't mean
the config file should be locked into that same config.
When you say hierarchical, what do you mean here WRT configuration?
What would the JSON look like there?
Dan
>
>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.)
Yes, name of team device could be anything.
>
>> 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 do not see why this is problem.
>
>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'?
Yes, they suppose to be unconfigured. Although I'm thinking that they
could be threated similar as bond slaves or bridge ports.
>
>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.
Team is not duplicate of bonding. It does similar thing but in
completely different way. Team ambition is to superseed all bonding
functionality so bonding will found itself obsolete.
>
>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.
>
Okay, this is good idea. I think I'll go this way for now. (Although I'm
not sure how to deal with team port/slaves in this scenario)
Thanks Bill.
Jirka
>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