[Openstack-operators] Potential updates to networking guide deployment scenarios

Kevin Benton blak111 at gmail.com
Sat Dec 5 19:15:05 UTC 2015

Could you maybe go with option 1 and have the part allowing tenants to
attach directly to the external network at the bottom as a separate section?

"If you want to allow tenants to attach directly to these networks as well,
continue reading."

Then it has one step where you mark the network as 'shared' as well and
it's done. ;)

On Fri, Dec 4, 2015 at 5:03 PM, Matt Kassawara <mkassawara at gmail.com> wrote:

> 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/
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151205/cba0ff2d/attachment.html>

More information about the OpenStack-operators mailing list