Merge "update quantum admin guide "limitations" section for grizzly"

doc/src/docbkx/openstack-network-connectivity-admin/ch_limitations.xml

@@ -6,43 +6,24 @@
     <title>Limitations</title>
     <para>
         <itemizedlist>
-            <listitem>
-                <para><emphasis>OpenStack Networking overlapping IPs
-                        do not work with Nova security groups or Nova
-                        metadata server:</emphasis> Nova was designed
-                    assuming that a particular IP address will only
-                    ever be used by a single VM at any time. OpenStack
-                    Networking supports overlapping IPs if the
-                    allow_overlapping_ips config value is set to
-                    'True'. We default this value to false to prevent
-                    unintentionally running Nova security groups or
-                    metadata server with overlapping IPs. If you
-                    enable this flag, you must disable both Nova
-                    security groups and the Nova metadata
-                    service.</para>
-            </listitem>
             <listitem>
                 <para><emphasis>No equivalent for nova-network
                         --multi_host flag:</emphasis> Nova-network has
                     a model where the L3, NAT, and DHCP processing
                     happen on the compute node itself, rather than a
                     dedicated networking node. OpenStack Networking
-                    does not have an equivalent configuration, but is
+                    now support running multiple l3-agent and dhcp-agents
-                    likely to add a similar capability in the future.
+                    with load being split across those agents, but the
-                    However, since the nova-network multi_host design
+                    tight coupling of that scheduling with the location of
-                    has some significant limitations in terms of
+                    the VM is not supported in Grizzly.  The Havana release is expected
-                    deployment scale (limited to a single physical L2)
+                    to include an exact replacement for the --multi_host flag
-                    and L3 forwarding behavior (does not map to a
+                    in nova-network.</para>
-                    single L3 router for traffic between instances on
-                    separate networks), the OpenStack Networking
-                    feature may not be an exact match, or may be
-                    limited to a subnet of all OpenStack Networking
-                    deployment scenarios. </para>
             </listitem>
             <listitem>
                 <para><emphasis>Linux network namespace required on
                         nodes running quantum-l3-agent or
-                        quantum-dhcp-agent: </emphasis>. In order to
+                        quantum-dhcp-agent if overlapping IPs are in use: </emphasis>.
+                    In order to
                     support overlapping IP addresses, the OpenStack
                     Networking DHCP and L3 agents use Linux network
                     namespaces by default. The hosts running these
@@ -87,23 +68,12 @@ ip netns exec test-ns ifconfig</computeroutput></screen>
             </listitem>
         </itemizedlist>
         <itemizedlist><listitem>
-                <para><emphasis>No IPv6 support for L3 agent:</emphasis> The quantum-l3-agent
+                <para><emphasis>No IPv6 support for L3 agent:</emphasis> The quantum-l3-agent, used
+                    by many plugins to implement L3 forwarding,
                     supports only IPv4 forwarding. Currently, There are no errors provided if you
                     configure IPv6 addresses via the API.</para>
-            </listitem><listitem>
+            </listitem>
-                <para><emphasis>L3 Agent supports limited scale for
+            <listitem>
-                        OpenStack Networking Routers:</emphasis> The
-                    L3 agent polls the OpenStack Networking API to
-                    learn about changes to L3 configuration. If there
-                    are a large number of routers or router ports,
-                    this can lead to heavy load on the database used
-                    by an OpenStack Networking plugin. The suggested
-                    work-around is to increase the polling_interval
-                    value in l3_agent.ini . This will increase the
-                    possible time between when a L3 configuration
-                    change happens via the API and when it affects
-                    data forwarding.</para>
-            </listitem><listitem>
                 <para><emphasis>ZeroMQ support is experimental</emphasis>: Some agents, including
                     quantum-dhcp-agent, quantum-openvswitch-agent, and quantum-linuxbridge-agent use
                     RPC to communicate. ZeroMQ is an available option in the configuration file, but
@@ -115,15 +85,7 @@ ip netns exec test-ns ifconfig</computeroutput></screen>
                     different API requests, based on the content of those API requests. This
                     functionality has not been widely reviewed or tested by the core team, and
                     should be considered experimental until further validation is performed. </para>
-            </listitem><listitem>
+            </listitem>
-                <para><emphasis>Horizon does not support
+           </itemizedlist>
-                        Routers/Floating IPs with OpenStack
-                        Networking:</emphasis> Horizon support is
-                    limited to operations on OpenStack Networking
-                    Networks, Subnets, and Ports. Routers and Floating
-                    IPs must be configured via CLI.</para>
-            </listitem><listitem>
-                <para>L3 Router Extension does not support IPv6.</para>
-            </listitem></itemizedlist>
     </para>
 </chapter>