Skip to content

Commit

Permalink
Include ML2 plugin documentation
Browse files Browse the repository at this point in the history 
Add ML2 plugin references and description
Include VXLAN as provider network
Add a deprecation note for openvswitch and linuxbridge plugins

Fix bug #1230283

Change-Id: I5710f81601fdb04b752737dfa0f36fc7863cca9e
  • Loading branch information
@emagana
emagana committed Oct 6, 2013
1 parent 1b20fb9 commit 2f5084c
Show file tree
Hide file tree
Showing 3 changed files with 95 additions and 54 deletions.
88 changes: 59 additions & 29 deletions doc/admin-guide-cloud/ch_networking.xml
View file
Expand Up @@ -140,16 +140,20 @@
<para><emphasis role="bold">Mellanox
Plug-in</emphasis>. <link
xlink:href="https://wiki.openstack.org/wiki/Mellanox-Neutron/"
>
https://wiki.openstack.org/wiki/Mellanox-Neutron/</link>
>https://wiki.openstack.org/wiki/Mellanox-Neutron/</link>
</para>
</listitem>
<listitem>
<para><emphasis role="bold">Midonet
Plug-in</emphasis>. <link
xlink:href="http://www.midokura.com/">
http://www.midokura.com/</link>
</para>
Plug-in</emphasis>. <link
xlink:href="http://www.midokura.com/">
http://www.midokura.com/</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">ML2 (Modular Layer 2)
Plug-in</emphasis>. <link
xlink:href="https://wiki.openstack.org/wiki/Neutron/ML2">
https://wiki.openstack.org/wiki/Neutron/ML2</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">NEC OpenFlow
Expand Down Expand Up @@ -188,12 +192,24 @@
</para>
</listitem>
</itemizedlist>
<para>Plug-ins can have different properties for hardware
requirements, features, performance, scale, or
operator tools. Because Networking supports a large
number of plug-ins, the cloud administrator is able to
weigh different options and decide which networking
technology is right for the deployment.</para>
<para>Plug-ins can have different properties for hardware requirements, features,
performance, scale, or operator tools. Because Networking supports a large number of
plug-ins, the cloud administrator can weigh options to decide on the right
networking technology for the deployment.</para>
<para>In the Havana release, OpenStack Networking provides the <emphasis role="bold">Modular
Layer 2 (ML2)</emphasis> plug-in that can concurrently use multiple layer 2
networking technologies that are found in real-world data centers. It currently
works with the existing Open vSwitch, Linux Bridge, and Hyper-v L2 agents. The ML2
framework simplifies the addition of support for new L2 technologies and reduces the
effort that is required to add and maintain them compared to monolithic
plug-ins.</para>
<note>
<title>Plugins Deprecation Notice:</title>
<para>The Open vSwitch and Linux Bridge plug-ins are deprecated in the Havana
release and will be removed in the Icehouse release. All features have been
ported to the ML2 plug-in in the form of mechanism drivers. ML2 currently
provides Linux Bridge, Open vSwitch and Hyper-v mechanism drivers.</para>
</note>
<para>Not all Networking plug-ins are compatible with all
possible Compute drivers:</para>
<table rules="all">
Expand Down Expand Up @@ -275,6 +291,15 @@
<td/>
<td/>
</tr>
<tr>
<td>ML2</td>
<td>Yes</td>
<td/>
<td/>
<td>Yes</td>
<td/>
<td/>
</tr>
<tr>
<td>NEC OpenFlow</td>
<td>Yes</td>
Expand Down Expand Up @@ -338,7 +363,7 @@
deploying several processes on a variety of
hosts.</para>
<para>The Networking server uses the <systemitem
class="service">neutron-server</systemitem> daemon
class="service">neutron-server</systemitem> daemon
to expose the Networking API and to pass user requests
to the configured Networking plug-in for additional
processing. Typically, the plug-in requires access to
Expand All @@ -364,15 +389,15 @@
<listitem>
<para><emphasis role="bold">dhcp agent</emphasis>
(<literal>neutron-dhcp-agent</literal>).
Provides DHCP services to tenant networks. All
plug-ins use this agent. </para>
Provides DHCP services to tenant networks.
Some plug-ins use this agent. </para>
</listitem>
<listitem>
<para><emphasis role="bold">l3 agent</emphasis>
<literal>(neutron-l3-agent</literal>).
Provides L3/NAT forwarding to provide external
network access for VMs on tenant networks. All
plug-ins use this agent. </para>
network access for VMs on tenant networks.
Some plug-ins use this agent. </para>
</listitem>
</itemizedlist>
<para>These agents interact with the main neutron process
Expand Down Expand Up @@ -506,7 +531,7 @@
<para>The CLI includes a number of options. For details,
refer to the <link
xlink:href="http://docs.openstack.org/user-guide/content/"
><citetitle>OpenStack End User
><citetitle>OpenStack End User
Guide</citetitle></link>.</para>
<section xml:id="api_abstractions">
<title>API abstractions</title>
Expand Down Expand Up @@ -1034,8 +1059,8 @@
VM NIC is automatically created and
associated with the default security
group. You can configure <link
linkend="enabling_ping_and_ssh"
>security group rules</link> to
linkend="enabling_ping_and_ssh"
>security group rules</link> to
enable users to access the VM.</para>
</listitem>
<listitem>
Expand Down Expand Up @@ -1157,7 +1182,7 @@
Service endpoint. For more information about
authentication with the Identity Service, see <link
xlink:href="http://docs.openstack.org/api/openstack-identity-service/2.0/content/"
><citetitle>OpenStack Identity Service API v2.0
><citetitle>OpenStack Identity Service API v2.0
Reference</citetitle></link>. When the Identity
Service is enabled, it is not mandatory to specify the
tenant ID for resources in create requests because the
Expand Down Expand Up @@ -1205,7 +1230,7 @@
a policy, which is evaluated. For instance in
<code>create_subnet:
[["admin_or_network_owner"]]</code>, <emphasis
role="italic">create_subnet</emphasis> is a policy,
role="italic">create_subnet</emphasis> is a policy,
and <emphasis role="italic"
>admin_or_network_owner</emphasis> is a rule.</para>
<para>Policies are triggered by the Networking policy engine
Expand Down Expand Up @@ -1338,7 +1363,7 @@
helps prevent individual node failures. In general, you
can run <systemitem class="service"
>neutron-server</systemitem> and <systemitem
class="service">neutron-dhcp-agent</systemitem> in an
class="service">neutron-dhcp-agent</systemitem> in an
active-active fashion. You can run the <systemitem
class="service">neutron-l3-agent</systemitem> service
as active/passive, which avoids IP conflicts with respect
Expand All @@ -1352,18 +1377,18 @@
<itemizedlist>
<listitem>
<para>neutron-server: <link
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-server"
>https://github.com/madkiss/openstack-resource-agents</link></para>
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-server"
>https://github.com/madkiss/openstack-resource-agents</link></para>
</listitem>
<listitem>
<para>neutron-dhcp-agent : <link
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-dhcp"
>https://github.com/madkiss/openstack-resource-agents</link></para>
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-dhcp"
>https://github.com/madkiss/openstack-resource-agents</link></para>
</listitem>
<listitem>
<para>neutron-l3-agent : <link
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-l3"
>https://github.com/madkiss/openstack-resource-agents</link></para>
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-l3"
>https://github.com/madkiss/openstack-resource-agents</link></para>
</listitem>
</itemizedlist>
<note xmlns:db="http://docbook.org/ns/docbook">
Expand All @@ -1387,6 +1412,11 @@
</tr>
</thead>
<tbody>
<tr>
<td>ML2</td>
<td>True</td>
<td>True</td>
</tr>
<tr>
<td>Open vSwitch</td>
<td>True</td>
Expand Down
40 changes: 24 additions & 16 deletions doc/admin-guide-cloud/section_networking_adv_features.xml
View file
Expand Up @@ -27,8 +27,8 @@
additional provider attributes on all virtual networks,
and are able to specify these attributes in order to
create provider networks.</para>
<para>The provider extension is supported by the openvswitch
and linuxbridge plug-ins. Configuration of these plug-ins
<para>The provider extension is supported by the Open vSwitch
and Linux Bridge plug-ins. Configuration of these plug-ins
requires familiarity with this extension.</para>
<section xml:id="provider_terminology">
<title>Terminology</title>
Expand All @@ -42,7 +42,7 @@
network (identified by a UUID and optional
name) whose ports can be attached as vNICs to
Compute instances and to various Networking
agents. The openvswitch and linuxbridge
agents. The Open vSwitch and Linux Bridge
plug-ins each support several different
mechanisms to realize virtual networks.</para>
</listitem>
Expand Down Expand Up @@ -114,13 +114,23 @@
are not associated by Networking with specific
physical networks.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Virtual Extensible LAN
(VXLAN) network</emphasis>. VXLAN is a proposed
encapsulation protocol for running an overlay
network on existing Layer 3 infrastructure. An
overlay network is a virtual network that is
built on top of existing network Layer 2 and
Layer 3 technologies to support elastic compute
architectures.</para>
</listitem>
</itemizedlist>
<para>Both the openvswitch and linuxbridge plug-ins
support VLAN networks, flat networks, and local
networks. Only the openvswitch plug-in currently
supports GRE networks, provided that the host's Linux
kernel supports the required Open vSwitch
features.</para>
<para>The ML2, Open vSwitch and Linux Bridge plug-ins support
VLAN networks, flat networks, and local networks. Only
the ML2 and Open vSwitch plug-ins currently support GRE
and VXLAN networks, provided that the required features
exist in the hosts Linux kernel, Open vSwitch and iproute2
packages.</para>
</section>
<section xml:id="provider_attributes">
<title>Provider attributes</title>
Expand Down Expand Up @@ -688,11 +698,9 @@
<note>
<itemizedlist>
<listitem>
<para>To use the Compute security group API with
Networking, the Networking plug-in must
implement the security group API. The
following plug-ins currently implement this:
Nicira NVP, Open vSwitch, Linux Bridge, NEC,
<para>To use the Compute security group API with Networking, the Networking
plug-in must implement the security group API. The following plug-ins
currently implement this: ML2, Nicira NVP, Open vSwitch, Linux Bridge, NEC,
and Ryu.</para>
</listitem>
<listitem>
Expand Down Expand Up @@ -1402,8 +1410,8 @@
two instances to enable fast data plane failover.</para>
<note>
<para>The allowed-address-pairs extension is currently
only supported by the following plug-ins: Nicira NVP,
OpenvSwitch, and ML2.</para>
only supported by the following plug-ins: ML2, Nicira
NVP, and OpenvSwitch.</para>
</note>
<section xml:id="section_allowed_address_pairs_workflow">
<title>Basic allowed address pairs operations</title>
Expand Down
21 changes: 12 additions & 9 deletions doc/common/ch_getstart.xml
View file
Expand Up @@ -573,19 +573,22 @@
for action.</para>
</listitem>
<listitem>
<para>OpenStack Networking plug-ins and agents. Plugs and
unplugs ports, creates networks or subnets, and provides
IP addressing. These plug-ins and agents differ depending
on the vendor and technologies used in the particular
cloud. OpenStack Networking ships with plug-ins and agents
for Cisco virtual and physical switches, Nicira NVP
product, NEC OpenFlow products, Open vSwitch, Linux
bridging, and the Ryu Network Operating System.</para>
<para><systemitem class="service"
>OpenStack Networking Plug-ins and Agents</systemitem>.
Plug and unplug ports, create networks or subnets, and
provide IP addressing. These plug-ins and agents differ
depending on the vendor and technologies used in the Cloud
System. OpenStack Networking ships with plug-ins and agents
for Arista, Brocade, Cisco NXOS as well as Nexus 1000V and
Mellanox switches, Linux bridging, Nicira NVP product, NEC
OpenFlow, Open vSwitch, PLUMgrid Platform, and the Ryu
Network Operating System.</para>
<para>The common agents are L3 (layer 3), DHCP (dynamic host
IP addressing), and a plug-in agent.</para>
</listitem>
<listitem>
<para>Messaging queue. Most OpenStack Networking
<para><systemitem class="service"
>Messaging Queue</systemitem>. Most OpenStack Networking
installations make use of a messaging queue to route
information between the neutron-server and various agents
as well as a database to store networking state for
Expand Down

0 comments on commit 2f5084c

Please sign in to comment.