openstack/openstack-manuals
Code Issues Proposed changes

update quantum admin guide "limitations" section for grizzly

Browse Source 
bug 1156794

Change-Id: Iab57a1bcf78edaac2e731673a8d369e92d453142
This commit is contained in:
Dan Wendlandt 2013-03-18 12:53:23 -07:00
parent dee7322de4
commit f958b172a6
1 changed files with 14 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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
likely to add a similar capability in the future.
However, since the nova-network multi_host design
has some significant limitations in terms of
deployment scale (limited to a single physical L2)
and L3 forwarding behavior (does not map to a
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>
now support running multiple l3-agent and dhcp-agents
with load being split across those agents, but the
tight coupling of that scheduling with the location of
the VM is not supported in Grizzly. The Havana release is expected
to include an exact replacement for the --multi_host flag
in nova-network.</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>
<para><emphasis>L3 Agent supports limited scale for
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>
</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>
<para><emphasis>Horizon does not support
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>
</listitem>
</itemizedlist>
</para>
</chapter>