Re: [ovs-dev] [PATCH 07/15] doc: Convert WHY-OVS to rST
On Tue, Oct 25, 2016 at 5:55 AM, Russell Bryant wrote: > > > On Sun, Oct 23, 2016 at 8:00 AM, Stephen Fincane > wrote: > >> On Fri, 2016-10-21 at 16:09 -0400, Russell Bryant wrote: >> > >> > >> > On Tue, Oct 18, 2016 at 4:03 PM, Stephen Finucane >> > wrote: >> > > Signed-off-by: Stephen Finucane >> >> [snip] >> >> > > +The advantage of hardware integration is not only performance >> > > within >> > > +virtualized environments. If physical switches also expose the >> > > Open vSwitch >> > > +control abstractions, both bare-metal and virtualized hosting >> > > environments can >> > > +be managed using the same mechanism for automated network control. >> > > + >> > > +In many ways, Open vSwitch targets a different point in the design >> > > space than >> > > +previous hypervisor networking stacks, focusing on the need for >> > > automated and >> > > +dynamic network control in large-scale Linux-based virtualization >> > > environments. >> > > + >> > > +The goal with Open vSwitch is to keep the in-kernel code as small >> > > as possible >> > > +(as is necessary for performance) and to re-use existing >> > > subsystems when >> > > +applicable (for example Open vSwitch uses the existing QoS stack). >> > > As of Linux >> > > +3.3, Open vSwitch is included as a part of the kernel and >> > > packaging for the >> > > +userspace utilities are available on most popular distributions. >> > >> > These last two paragraphs were not part of the "hardware integration" >> > section in the original doc. They were the closing paragraphs of the >> > document. I haven't thought of a good heading for them, though. >> > Maybe "design"? Thoughts? >> >> Good catch. Totally up to you, though. I'd suggest "conclusion" or >> "summary", but I'm also fine with "design". >> > > Good idea, I like "conclusion" or "summary". I'll use one of those. > I made the following change and applied this to master. diff --git a/WHY-OVS.rst b/WHY-OVS.rst index 161889d..5cfd721 100644 --- a/WHY-OVS.rst +++ b/WHY-OVS.rst @@ -117,6 +117,9 @@ virtualized environments. If physical switches also expose the Open vSwitch control abstractions, both bare-metal and virtualized hosting environments can be managed using the same mechanism for automated network control. +Summary +--- + In many ways, Open vSwitch targets a different point in the design space than previous hypervisor networking stacks, focusing on the need for automated and dynamic network control in large-scale Linux-based virtualization environments. -- Russell Bryant ___ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/15] doc: Convert WHY-OVS to rST
On Sun, Oct 23, 2016 at 8:00 AM, Stephen Fincane wrote: > On Fri, 2016-10-21 at 16:09 -0400, Russell Bryant wrote: > > > > > > On Tue, Oct 18, 2016 at 4:03 PM, Stephen Finucane > > wrote: > > > Signed-off-by: Stephen Finucane > > [snip] > > > > +The advantage of hardware integration is not only performance > > > within > > > +virtualized environments. If physical switches also expose the > > > Open vSwitch > > > +control abstractions, both bare-metal and virtualized hosting > > > environments can > > > +be managed using the same mechanism for automated network control. > > > + > > > +In many ways, Open vSwitch targets a different point in the design > > > space than > > > +previous hypervisor networking stacks, focusing on the need for > > > automated and > > > +dynamic network control in large-scale Linux-based virtualization > > > environments. > > > + > > > +The goal with Open vSwitch is to keep the in-kernel code as small > > > as possible > > > +(as is necessary for performance) and to re-use existing > > > subsystems when > > > +applicable (for example Open vSwitch uses the existing QoS stack). > > > As of Linux > > > +3.3, Open vSwitch is included as a part of the kernel and > > > packaging for the > > > +userspace utilities are available on most popular distributions. > > > > These last two paragraphs were not part of the "hardware integration" > > section in the original doc. They were the closing paragraphs of the > > document. I haven't thought of a good heading for them, though. > > Maybe "design"? Thoughts? > > Good catch. Totally up to you, though. I'd suggest "conclusion" or > "summary", but I'm also fine with "design". > Good idea, I like "conclusion" or "summary". I'll use one of those. -- Russell Bryant ___ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/15] doc: Convert WHY-OVS to rST
On Fri, 2016-10-21 at 16:09 -0400, Russell Bryant wrote: > > > On Tue, Oct 18, 2016 at 4:03 PM, Stephen Finucane > wrote: > > Signed-off-by: Stephen Finucane [snip] > > +The advantage of hardware integration is not only performance > > within > > +virtualized environments. If physical switches also expose the > > Open vSwitch > > +control abstractions, both bare-metal and virtualized hosting > > environments can > > +be managed using the same mechanism for automated network control. > > + > > +In many ways, Open vSwitch targets a different point in the design > > space than > > +previous hypervisor networking stacks, focusing on the need for > > automated and > > +dynamic network control in large-scale Linux-based virtualization > > environments. > > + > > +The goal with Open vSwitch is to keep the in-kernel code as small > > as possible > > +(as is necessary for performance) and to re-use existing > > subsystems when > > +applicable (for example Open vSwitch uses the existing QoS stack). > > As of Linux > > +3.3, Open vSwitch is included as a part of the kernel and > > packaging for the > > +userspace utilities are available on most popular distributions. > > These last two paragraphs were not part of the "hardware integration" > section in the original doc. They were the closing paragraphs of the > document. I haven't thought of a good heading for them, though. > Maybe "design"? Thoughts? Good catch. Totally up to you, though. I'd suggest "conclusion" or "summary", but I'm also fine with "design". Stephen ___ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 07/15] doc: Convert WHY-OVS to rST
On Tue, Oct 18, 2016 at 4:03 PM, Stephen Finucane wrote: > Signed-off-by: Stephen Finucane > --- > FAQ.md | 4 +- > Makefile.am | 2 +- > WHY-OVS.md | 106 - > WHY-OVS.rst | 128 ++ > ++ > rhel/openvswitch-fedora.spec.in | 2 +- > rhel/openvswitch.spec.in| 2 +- > tests/run-oftest| 2 +- > tests/run-ryu | 2 +- > tutorial/ovs-sandbox| 2 +- > utilities/ovs-dev.py| 2 +- > utilities/ovs-sim.in| 4 +- > 11 files changed, 139 insertions(+), 117 deletions(-) > delete mode 100644 WHY-OVS.md > create mode 100644 WHY-OVS.rst > > diff --git a/FAQ.md b/FAQ.md > index 9ab5210..420e40e 100644 > --- a/FAQ.md > +++ b/FAQ.md > @@ -83,7 +83,7 @@ A: The [PORTING.rst] document describes how one would go > about > A: Open vSwitch is specially designed to make it easier to manage VM > network configuration and monitor state spread across many physical > hosts in dynamic virtualized environments. Please see > - [WHY-OVS.md] for a more detailed description of how Open vSwitch > + [WHY-OVS.rst] for a more detailed description of how Open vSwitch > relates to the Linux Bridge. > > ### Q: How is Open vSwitch related to distributed virtual switches like > the VMware vNetwork distributed switch or the Cisco Nexus 1000V? > @@ -2150,7 +2150,7 @@ [email protected] > http://openvswitch.org/ > > [PORTING.rst]:PORTING.rst > -[WHY-OVS.md]:WHY-OVS.md > +[WHY-OVS.rst]:WHY-OVS.rst > [INSTALL.rst]:INSTALL.rst > [OPENFLOW-1.1+.md]:OPENFLOW-1.1+.md > [INSTALL.DPDK.rst]:INSTALL.DPDK.rst > diff --git a/Makefile.am b/Makefile.am > index dc92b71..9373a04 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -94,7 +94,7 @@ docs = \ > README-native-tunneling.md \ > REPORTING-BUGS.rst \ > SECURITY.md \ > - WHY-OVS.md > + WHY-OVS.rst > EXTRA_DIST = \ > $(docs) \ > NOTICE \ > diff --git a/WHY-OVS.md b/WHY-OVS.md > deleted file mode 100644 > index d31e69e..000 > --- a/WHY-OVS.md > +++ /dev/null > @@ -1,106 +0,0 @@ > -Why Open vSwitch? > -= > - > -Hypervisors need the ability to bridge traffic between VMs and with the > -outside world. On Linux-based hypervisors, this used to mean using the > -built-in L2 switch (the Linux bridge), which is fast and reliable. So, > -it is reasonable to ask why Open vSwitch is used. > - > -The answer is that Open vSwitch is targeted at multi-server > -virtualization deployments, a landscape for which the previous stack is > -not well suited. These environments are often characterized by highly > -dynamic end-points, the maintenance of logical abstractions, and > -(sometimes) integration with or offloading to special purpose switching > -hardware. > - > -The following characteristics and design considerations help Open > -vSwitch cope with the above requirements. > - > -* The mobility of state: All network state associated with a network > - entity (say a virtual machine) should be easily identifiable and > - migratable between different hosts. This may include traditional > - "soft state" (such as an entry in an L2 learning table), L3 forwarding > - state, policy routing state, ACLs, QoS policy, monitoring > - configuration (e.g. NetFlow, IPFIX, sFlow), etc. > - > - Open vSwitch has support for both configuring and migrating both slow > - (configuration) and fast network state between instances. For > - example, if a VM migrates between end-hosts, it is possible to not > - only migrate associated configuration (SPAN rules, ACLs, QoS) but any > - live network state (including, for example, existing state which > - may be difficult to reconstruct). Further, Open vSwitch state is > - typed and backed by a real data-model allowing for the development of > - structured automation systems. > - > -* Responding to network dynamics: Virtual environments are often > - characterized by high-rates of change. VMs coming and going, VMs > - moving backwards and forwards in time, changes to the logical network > - environments, and so forth. > - > - Open vSwitch supports a number of features that allow a network > - control system to respond and adapt as the environment changes. > - This includes simple accounting and visibility support such as > - NetFlow, IPFIX, and sFlow. But perhaps more useful, Open vSwitch > - supports a network state database (OVSDB) that supports remote > - triggers. Therefore, a piece of orchestration software can "watch" > - various aspects of the network and respond if/when they change. > - This is used heavily today, for example, to respond to and track VM > - migrations. > - > - Open vSwitch also supports OpenFlow as a method of exporting remote > - access to control traffic. There are a number of uses for this > - including
