[networking-guide] master: Team: typos and style updates (943410b)

stephenw at fedoraproject.org stephenw at fedoraproject.org
Fri Jul 25 06:46:52 UTC 2014


Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git

On branch  : master

>---------------------------------------------------------------

commit 943410bb2a11a10060c6d1aa1d52f3eb66ce62da
Author: Stephen Wadeley <swadeley at redhat.com>
Date:   Mon Jul 21 22:50:22 2014 +0200

    Team: typos and style updates


>---------------------------------------------------------------

 en-US/Configure_Network_Teaming.xml |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 741170e..775eac7 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -12,7 +12,7 @@
      The combining or aggregating together of network links in order to provide a logical link with higher throughput, or to provide redundancy, is known by many names such as <quote>channel bonding</quote>, <quote>Ethernet bonding</quote>, <quote>port trunking</quote>, <quote>channel teaming</quote>, <quote>NIC teaming</quote>, <quote>link aggregation</quote>, and so on. This concept as originally implemented in the Linux kernel is widely referred to as <quote>bonding</quote>. The term Network Teaming has been chosen to refer to this new implementation of the concept. The existing bonding driver is unaffected, Network Teaming is offered as an alternative and does not replace bonding in <application>Fedora</application>.
    </para>
    <para>
-     Network Teaming, or Team, is designed to implement the concept in a different way by providing a small kernel driver to implement the fast handling of packet flows, and various user-space applications to do everything else in user space. The driver has an <firstterm>Application Programming Interface</firstterm> (<acronym>API</acronym>), referred to as <quote>Team Netlink API</quote>, which implements Netlink communications. User-space applications can use this API to communication with the driver. A library, referred to as <quote>lib</quote>, has been provided to do user space wrapping of Team Netlink communications and RT Netlink messages. An application daemon, <systemitem class="daemon">teamd</systemitem>, which uses Libteam lib is also provided. One instance of <systemitem class="daemon">teamd</systemitem> can control one instance of the Team driver. The daemon implements the load-balancing and active-backup logic, such as round-robin, by using additional code refer
 red to as <quote>runners</quote>. By separating the code in this way, the Network Teaming implementation presents an easily extensible and scalable solution for load-balancing and redundancy requirements. For example, custom runners can be relatively easily written to implement new logic via <systemitem class="daemon">teamd</systemitem>, and even <systemitem class="daemon">teamd</systemitem> is optional, users can write their own application to use <application>libteam</application>.
+     Network Teaming, or Team, is designed to implement the concept in a different way by providing a small kernel driver to implement the fast handling of packet flows, and various user-space applications to do everything else in user space. The driver has an <firstterm>Application Programming Interface</firstterm> (<acronym>API</acronym>), referred to as <quote>Team Netlink API</quote>, which implements Netlink communications. User-space applications can use this API to communicate with the driver. A library, referred to as <quote>lib</quote>, has been provided to do user space wrapping of Team Netlink communications and RT Netlink messages. An application daemon, <systemitem class="daemon">teamd</systemitem>, which uses Libteam lib is also provided. One instance of <systemitem class="daemon">teamd</systemitem> can control one instance of the Team driver. The daemon implements the load-balancing and active-backup logic, such as round-robin, by using additional code referre
 d to as <quote>runners</quote>. By separating the code in this way, the Network Teaming implementation presents an easily extensible and scalable solution for load-balancing and redundancy requirements. For example, custom runners can be relatively easily written to implement new logic via <systemitem class="daemon">teamd</systemitem>, and even <systemitem class="daemon">teamd</systemitem> is optional, users can write their own application to use <application>libteam</application>.
     </para>
     <para>
       A tool to control a running instance of <systemitem class="daemon">teamd</systemitem> using D-bus is provided by <application>teamdctl</application>. It provides a D-Bus wrapper around the <systemitem class="daemon">teamd</systemitem> D-Bus API. By default, <systemitem class="daemon">teamd</systemitem> listens and communicates using Unix Domain Sockets but still monitors D-Bus. This is to insure that <systemitem class="daemon">teamd</systemitem> can be used in environments where D-Bus is not present or not yet loaded. For example, when booting over <systemitem class="daemon">teamd</systemitem> links D-Bus would not yet be loaded. The <application>teamdctl</application> tool can be used during run time to read the configuration, the state of link-watchers, check and change the state of ports, add and remove ports, and to change ports between active and backup states. 
@@ -76,7 +76,7 @@
 <section id="sec-Understanding_the_Network_Teaming_Daemon_and_the_Runners">
   <title>Understanding the Network Teaming Daemon and the "Runners"</title>
   <para>
-The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <application>libteam</application> to control one instance of the team driver. This instance of the team driver enslaves instances of a hardware device driver to form a <quote>team</quote> of network links. The team driver presents a network interface, <interface>team0</interface> for example, to the other parts of the kernel. The interfaces created by instances of the team driver are given names such as <interface>team0</interface>, <interface>team1</interface>, and so forth in the documentation. This is for ease of understanding and other names can be used. The logic common to all methods of teaming is implemented by <systemitem class="daemon">teamd</systemitem> and those functions that are unique to the different load sharing and backup methods, such as round-robin, are implemented by separate units of code referred to as <quote>runners</quote>. Because words such as <quote>module</quote> and <quote>mode
 </quote> already have specific meanings in relation to the kernel, the word <quote>runner</quote> was chosen to refer to these units of code. The user specifies the runner in the <filename>teamd.conf</filename> file and the code is then compiled into an instance of <systemitem class="daemon">teamd</systemitem> when the instance is created. As the code for a <quote>runner</quote> is compiled into an instance of <systemitem class="daemon">teamd</systemitem> as it is being created, the code for a <quote>runner</quote> is not a plug-in, although code could be created as a plug-in for <systemitem class="daemon">teamd</systemitem> should the need arise.
+The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <application>libteam</application> to control one instance of the team driver. This instance of the team driver adds instances of a hardware device driver to form a <quote>team</quote> of network links. The team driver presents a network interface, <interface>team0</interface> for example, to the other parts of the kernel. The interfaces created by instances of the team driver are given names such as <interface>team0</interface>, <interface>team1</interface>, and so forth in the documentation. This is for ease of understanding and other names can be used. The logic common to all methods of teaming is implemented by <systemitem class="daemon">teamd</systemitem>; those functions that are unique to the different load sharing and backup methods, such as round-robin, are implemented by separate units of code referred to as <quote>runners</quote>. Because words such as <quote>module</quote> and <quote>mode</quote
 > already have specific meanings in relation to the kernel, the word <quote>runner</quote> was chosen to refer to these units of code. The user specifies the runner in the JSON format configuration file and the code is then compiled into an instance of <systemitem class="daemon">teamd</systemitem> when the instance is created. A runner is not a plug-in because the code for a runner is compiled into an instance of <systemitem class="daemon">teamd</systemitem> as it is being created. Code could be created as a plug-in for <systemitem class="daemon">teamd</systemitem> should the need arise.
   </para>
   <para>
     The following runners are available at time of writing.
@@ -127,7 +127,7 @@ The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <applicatio
      </para>
    </listitem>
       </itemizedlist>
-      There are no restrictions in the code to prevent a particular link-watcher from being used with a particular runner, however when using the <application>lacp</application> runner, <application>ethtool</application> is the only recommend link-watcher.
+      There are no restrictions in the code to prevent a particular link-watcher from being used with a particular runner, however when using the <application>lacp</application> runner, <application>ethtool</application> is the only recommended link-watcher.
   </para>
 </section>
 <!--Topics, Tasks:-->
@@ -397,7 +397,7 @@ activebackup_ethtool_3.conf   loadbalance_1.conf             roundrobin.conf</sc
   Make any necessary changes and save the file. See the <filename>vi(1)</filename> man page for help on using the <application>vi</application> editor or use your preferred editor.
 </para>
 <para>
-  Note that it is essential that the interfaces to be used as ports within the team must not be active, that is to say, they must be <quote>down</quote>, when enslave them into a team device. To check their status, issue the following command:
+  Note that it is essential that the interfaces to be used as ports within the team must not be active, that is to say, they must be <quote>down</quote>, when adding them into a team device. To check their status, issue the following command:
   <screen>~]$ <command>ip link show</command>
 1: lo: &lt;LOOPBACK,UP,LOWER_UP&gt; mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
@@ -511,7 +511,7 @@ NM_CONTROLLED="no"</screen>
 Add additional slave interfaces similar to the above as required, changing the DEVICE and HWADDR field to match the ports (the network devices) being enslaved. If port priority is not specified by <literal>prio</literal> it defaults to <literal>0</literal>; it accepts negative and positive values in the range <literal>-32,767</literal> to <literal>+32,767</literal>. 
 </para>
       <para>
-        Specifying the hardware or MAC address using the <command>HWADDR</command> directive will influence the device naming procedure as explained in <xref linkend="ch-Consistent_Network_Device_Naming" />.
+        Specifying the hardware or MAC address using the <command>HWADDR</command> directive will influence the device naming procedure. This is explained in <xref linkend="ch-Consistent_Network_Device_Naming" />.
       </para>
 
 
@@ -566,7 +566,7 @@ em1: up 100 fullduplex</screen>
 <section id="sec-Bring_Up_an_interface_to_a_Network_Team_Using_iputils">
   <title>Bring up an Interface to a Network Team Using iputils</title>
   <para>
-    To active or <quote>bring up</quote> an interface to a network team, <interface>team0</interface>, using the <application>ip</application> utility, issue the following command as <systemitem class="username">root</systemitem>:
+    To activate or <quote>bring up</quote> an interface to a network team, <interface>team0</interface>, using the <application>ip</application> utility, issue the following command as <systemitem class="username">root</systemitem>:
     <screen>~]# <command>ip link set team0 up</command></screen>
   </para>
 </section>



More information about the docs-commits mailing list