Open Stack

The networking guide [1] contains deployment scenarios [2] that describe
the operation of several common OpenStack Networking (neutron)
architectures including functional configuration examples.

Currently, the legacy and L3HA scenarios [3][4][5][6] only support
attaching VMs to private/internal/project networks (managed by projects)
with a combination of routers and floating IPs that provide connectivity to
external networks such as the Internet. However, L3 support regardless of
architecture adds complexity and can introduce redundancy/performance
concerns.

On the other hand, the provider networks scenarios [7][8] only support
attaching VMs to public/external/provider networks (managed by
administrators) and exclude components such as private networks, routers,
and floating IPs.

Turns out... you can do both. In fact, the installation guide for Liberty
[9] supports attaching VMs to both public and private networks. No choosing
between the simplicity of provider networks and the "self-service" nature
of true cloud networking in your deployment.

So, I propose that we update the legacy and L3HA scenarios in the
networking guide to support attaching VMs to both public and private
networks using one of the following options:

1) Add support for attaching VMs to public networks to the existing
scenarios.
2) Create additional scenarios that support attaching VMs to both public
and private networks.
3) Restructure the existing scenarios by starting out with simple provider
networks architectures for both Open vSwitch and Linux bridge and
optionally adding L3 support to them. The installation guide for Liberty
uses this approach.

Option 1 somewhat increases complexity of scenarios that our audience may
already find difficult to comprehend. Option 2 proliferates the scenarios
and makes it more difficult for our audience to choose the best one for a
particular deployment. In addition, it can lead to duplication of content
that becomes difficult to keep consistent. Option 3 requires a more complex
documentation structure that our audience may find difficult to follow. As
the audience, I would like your input on the usefulness of these potential
updates and which option works best... or add another option.

Thanks,
Matt

[1] http://docs.openstack.org/networking-guide/
[2] http://docs.openstack.org/networking-guide/deploy.html
[3] http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html
[4] http://docs.openstack.org/networking-guide/scenario_legacy_lb.html
[5] http://docs.openstack.org/networking-guide/scenario_l3ha_ovs.html
[6] http://docs.openstack.org/networking-guide/scenario_l3ha_lb.html
[7] http://docs.openstack.org/networking-guide/scenario_provider_ovs.html
[8] http://docs.openstack.org/networking-guide/scenario_provider_lb.html
[9] http://docs.openstack.org/liberty/install-guide-ubuntu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151204/89a2303a/attachment.html>