openstack/openstack-manuals
Code Issues Proposed changes

Merge "Include ML2 plugin documentation"

Browse Source
This commit is contained in:
Jenkins 2013-10-07 20:05:15 +00:00 committed by Gerrit Code Review
commit d3a8008e0a
3 changed files with 95 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
doc/admin-guide-cloud/ch_networking.xml
View File

@ -140,16 +140,20 @@
<para><emphasis role="bold">Mellanox <para><emphasis role="bold">Mellanox
Plug-in</emphasis>. <link Plug-in</emphasis>. <link
xlink:href="https://wiki.openstack.org/wiki/Mellanox-Neutron/" 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> </para>
</listitem> </listitem>
<listitem> <listitem>
<para><emphasis role="bold">Midonet <para><emphasis role="bold">Midonet
Plug-in</emphasis>. <link Plug-in</emphasis>. <link
xlink:href="http://www.midokura.com/"> xlink:href="http://www.midokura.com/">
http://www.midokura.com/</link> http://www.midokura.com/</link></para>
</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>
<listitem> <listitem>
<para><emphasis role="bold">NEC OpenFlow <para><emphasis role="bold">NEC OpenFlow
@ -188,12 +192,24 @@
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
<para>Plug-ins can have different properties for hardware <para>Plug-ins can have different properties for hardware requirements, features,
requirements, features, performance, scale, or performance, scale, or operator tools. Because Networking supports a large number of
operator tools. Because Networking supports a large plug-ins, the cloud administrator can weigh options to decide on the right
number of plug-ins, the cloud administrator is able to networking technology for the deployment.</para>
weigh different options and decide which networking <para>In the Havana release, OpenStack Networking provides the <emphasis role="bold">Modular
technology is right for the deployment.</para> 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 <para>Not all Networking plug-ins are compatible with all
possible Compute drivers:</para> possible Compute drivers:</para>
<table rules="all"> <table rules="all">
@ -275,6 +291,15 @@
<td/> <td/>
<td/> <td/>
</tr> </tr>
<tr>
<td>ML2</td>
<td>Yes</td>
<td/>
<td/>
<td>Yes</td>
<td/>
<td/>
</tr>
<tr> <tr>
<td>NEC OpenFlow</td> <td>NEC OpenFlow</td>
<td>Yes</td> <td>Yes</td>
@ -338,7 +363,7 @@
deploying several processes on a variety of deploying several processes on a variety of
hosts.</para> hosts.</para>
<para>The Networking server uses the <systemitem <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 expose the Networking API and to pass user requests
to the configured Networking plug-in for additional to the configured Networking plug-in for additional
processing. Typically, the plug-in requires access to processing. Typically, the plug-in requires access to
@ -364,15 +389,15 @@
<listitem> <listitem>
<para><emphasis role="bold">dhcp agent</emphasis> <para><emphasis role="bold">dhcp agent</emphasis>
(<literal>neutron-dhcp-agent</literal>). (<literal>neutron-dhcp-agent</literal>).
Provides DHCP services to tenant networks. All Provides DHCP services to tenant networks.
plug-ins use this agent. </para> Some plug-ins use this agent. </para>
</listitem> </listitem>
<listitem> <listitem>
<para><emphasis role="bold">l3 agent</emphasis> <para><emphasis role="bold">l3 agent</emphasis>
<literal>(neutron-l3-agent</literal>). <literal>(neutron-l3-agent</literal>).
Provides L3/NAT forwarding to provide external Provides L3/NAT forwarding to provide external
network access for VMs on tenant networks. All network access for VMs on tenant networks.
plug-ins use this agent. </para> Some plug-ins use this agent. </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
<para>These agents interact with the main neutron process <para>These agents interact with the main neutron process
@ -506,7 +531,7 @@
<para>The CLI includes a number of options. For details, <para>The CLI includes a number of options. For details,
refer to the <link refer to the <link
xlink:href="http://docs.openstack.org/user-guide/content/" xlink:href="http://docs.openstack.org/user-guide/content/"
><citetitle>OpenStack End User ><citetitle>OpenStack End User
Guide</citetitle></link>.</para> Guide</citetitle></link>.</para>
<section xml:id="api_abstractions"> <section xml:id="api_abstractions">
<title>API abstractions</title> <title>API abstractions</title>
@ -1034,8 +1059,8 @@
VM NIC is automatically created and VM NIC is automatically created and
associated with the default security associated with the default security
group. You can configure <link group. You can configure <link
linkend="enabling_ping_and_ssh" linkend="enabling_ping_and_ssh"
>security group rules</link> to >security group rules</link> to
enable users to access the VM.</para> enable users to access the VM.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -1157,7 +1182,7 @@
Service endpoint. For more information about Service endpoint. For more information about
authentication with the Identity Service, see <link authentication with the Identity Service, see <link
xlink:href="http://docs.openstack.org/api/openstack-identity-service/2.0/content/" 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 Reference</citetitle></link>. When the Identity
Service is enabled, it is not mandatory to specify the Service is enabled, it is not mandatory to specify the
tenant ID for resources in create requests because the tenant ID for resources in create requests because the
@ -1205,7 +1230,7 @@
a policy, which is evaluated. For instance in a policy, which is evaluated. For instance in
<code>create_subnet: <code>create_subnet:
[["admin_or_network_owner"]]</code>, <emphasis [["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" and <emphasis role="italic"
>admin_or_network_owner</emphasis> is a rule.</para> >admin_or_network_owner</emphasis> is a rule.</para>
<para>Policies are triggered by the Networking policy engine <para>Policies are triggered by the Networking policy engine
@ -1338,7 +1363,7 @@
helps prevent individual node failures. In general, you helps prevent individual node failures. In general, you
can run <systemitem class="service" can run <systemitem class="service"
>neutron-server</systemitem> and <systemitem >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 active-active fashion. You can run the <systemitem
class="service">neutron-l3-agent</systemitem> service class="service">neutron-l3-agent</systemitem> service
as active/passive, which avoids IP conflicts with respect as active/passive, which avoids IP conflicts with respect
@ -1352,18 +1377,18 @@
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>neutron-server: <link <para>neutron-server: <link
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-server" xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-server"
>https://github.com/madkiss/openstack-resource-agents</link></para> >https://github.com/madkiss/openstack-resource-agents</link></para>
</listitem> </listitem>
<listitem> <listitem>
<para>neutron-dhcp-agent : <link <para>neutron-dhcp-agent : <link
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-dhcp" xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-dhcp"
>https://github.com/madkiss/openstack-resource-agents</link></para> >https://github.com/madkiss/openstack-resource-agents</link></para>
</listitem> </listitem>
<listitem> <listitem>
<para>neutron-l3-agent : <link <para>neutron-l3-agent : <link
xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-l3" xlink:href="https://github.com/madkiss/openstack-resource-agents/blob/master/ocf/neutron-agent-l3"
>https://github.com/madkiss/openstack-resource-agents</link></para> >https://github.com/madkiss/openstack-resource-agents</link></para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
<note xmlns:db="http://docbook.org/ns/docbook"> <note xmlns:db="http://docbook.org/ns/docbook">
@ -1387,6 +1412,11 @@
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr>
<td>ML2</td>
<td>True</td>
<td>True</td>
</tr>
<tr> <tr>
<td>Open vSwitch</td> <td>Open vSwitch</td>
<td>True</td> <td>True</td>

40
doc/admin-guide-cloud/section_networking_adv_features.xml
View File

@ -27,8 +27,8 @@
additional provider attributes on all virtual networks, additional provider attributes on all virtual networks,
and are able to specify these attributes in order to and are able to specify these attributes in order to
create provider networks.</para> create provider networks.</para>
<para>The provider extension is supported by the openvswitch <para>The provider extension is supported by the Open vSwitch
and linuxbridge plug-ins. Configuration of these plug-ins and Linux Bridge plug-ins. Configuration of these plug-ins
requires familiarity with this extension.</para> requires familiarity with this extension.</para>
<section xml:id="provider_terminology"> <section xml:id="provider_terminology">
<title>Terminology</title> <title>Terminology</title>
@ -42,7 +42,7 @@
network (identified by a UUID and optional network (identified by a UUID and optional
name) whose ports can be attached as vNICs to name) whose ports can be attached as vNICs to
Compute instances and to various Networking Compute instances and to various Networking
agents. The openvswitch and linuxbridge agents. The Open vSwitch and Linux Bridge
plug-ins each support several different plug-ins each support several different
mechanisms to realize virtual networks.</para> mechanisms to realize virtual networks.</para>
</listitem> </listitem>
@ -114,13 +114,23 @@
are not associated by Networking with specific are not associated by Networking with specific
physical networks.</para> physical networks.</para>
</listitem> </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> </itemizedlist>
<para>Both the openvswitch and linuxbridge plug-ins <para>The ML2, Open vSwitch and Linux Bridge plug-ins support
support VLAN networks, flat networks, and local VLAN networks, flat networks, and local networks. Only
networks. Only the openvswitch plug-in currently the ML2 and Open vSwitch plug-ins currently support GRE
supports GRE networks, provided that the host's Linux and VXLAN networks, provided that the required features
kernel supports the required Open vSwitch exist in the hosts Linux kernel, Open vSwitch and iproute2
features.</para> packages.</para>
</section> </section>
<section xml:id="provider_attributes"> <section xml:id="provider_attributes">
<title>Provider attributes</title> <title>Provider attributes</title>
@ -688,11 +698,9 @@
<note> <note>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>To use the Compute security group API with <para>To use the Compute security group API with Networking, the Networking
Networking, the Networking plug-in must plug-in must implement the security group API. The following plug-ins
implement the security group API. The currently implement this: ML2, Nicira NVP, Open vSwitch, Linux Bridge, NEC,
following plug-ins currently implement this:
Nicira NVP, Open vSwitch, Linux Bridge, NEC,
and Ryu.</para> and Ryu.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -1402,8 +1410,8 @@
two instances to enable fast data plane failover.</para> two instances to enable fast data plane failover.</para>
<note> <note>
<para>The allowed-address-pairs extension is currently <para>The allowed-address-pairs extension is currently
only supported by the following plug-ins: Nicira NVP, only supported by the following plug-ins: ML2, Nicira
OpenvSwitch, and ML2.</para> NVP, and OpenvSwitch.</para>
</note> </note>
<section xml:id="section_allowed_address_pairs_workflow"> <section xml:id="section_allowed_address_pairs_workflow">
<title>Basic allowed address pairs operations</title> <title>Basic allowed address pairs operations</title>

21
doc/common/ch_getstart.xml
View File

@ -573,19 +573,22 @@
for action.</para> for action.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>OpenStack Networking plug-ins and agents. Plugs and <para><systemitem class="service"
unplugs ports, creates networks or subnets, and provides >OpenStack Networking Plug-ins and Agents</systemitem>.
IP addressing. These plug-ins and agents differ depending Plug and unplug ports, create networks or subnets, and
on the vendor and technologies used in the particular provide IP addressing. These plug-ins and agents differ
cloud. OpenStack Networking ships with plug-ins and agents depending on the vendor and technologies used in the Cloud
for Cisco virtual and physical switches, Nicira NVP System. OpenStack Networking ships with plug-ins and agents
product, NEC OpenFlow products, Open vSwitch, Linux for Arista, Brocade, Cisco NXOS as well as Nexus 1000V and
bridging, and the Ryu Network Operating System.</para> 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 <para>The common agents are L3 (layer 3), DHCP (dynamic host
IP addressing), and a plug-in agent.</para> IP addressing), and a plug-in agent.</para>
</listitem> </listitem>
<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 installations make use of a messaging queue to route
information between the neutron-server and various agents information between the neutron-server and various agents
as well as a database to store networking state for as well as a database to store networking state for