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

Matt Kassawara mkassawara at gmail.com
Sat Dec 5 23:06:52 UTC 2015

I wish it was that easy... the external network currently only attaches to
the network node.

On Sat, Dec 5, 2015 at 12:15 PM, Kevin Benton <blak111 at gmail.com> wrote:

> 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/52d065dc/attachment.html>

More information about the OpenStack-operators mailing list