[patch initscripts] Add support for network team device.

[Jiri Pirko]

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"]}'

Signed-off-by: Jiri Pirko <jpirko(a)redhat.com&gt;
---
 sysconfig/network-scripts/ifdown-eth |    8 ++++++++
 sysconfig/network-scripts/ifup-eth   |    9 +++++++++
 2 files changed, 17 insertions(+), 0 deletions(-)

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
+
 if [ "${TYPE}" = "Tap" ]; then
 	tunctl -d "${DEVICE}" >/dev/null
 fi
diff --git a/sysconfig/network-scripts/ifup-eth b/sysconfig/network-scripts/ifup-eth
index 5d2cff5..d451975 100755
--- a/sysconfig/network-scripts/ifup-eth
+++ b/sysconfig/network-scripts/ifup-eth
@@ -64,6 +64,15 @@ if [ "${TYPE}" = "Bridge" ]; then
       done
 fi
 
+# 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
+
 # If the device is a tap device, create it with tunctl, if available.
 if [ "${TYPE}" = "Tap" ]; then
       if [ ! -x /usr/sbin/tunctl ]; then
-- 
1.7.7.6

[Bill Nottingham]

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

[Jiri Pirko]

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.


> 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

[Dan Williams]

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

[Jiri Pirko]

Wed, Feb 01, 2012 at 10:00:09PM CET, dcbw(a)redhat.com wrote:
> 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? 
{
        "device":       "team0",
        "runner":       "activebackup_linkmon",
        "ports":        {
                                "eth1": {
                                        "prio": -10,
                                        "sticky": true
                                },
                                "eth2": {
                                        "prio": 100
                                }
                        }
}

And other options and levels are going to come in near future.

I guess to avoid json, TEAM_CONFIG might look like this:
TEAM_CONFIG="device=team0 runner=activebackup_linkmon ports.eth1.prio=-10
ports.eth1.sticky=true ports.eth2.prio=100"

but that would cause a need to translate this string into json.

> 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
>
>