[Openstack-operators] Potential updates to networking guide deployment scenarios
jamesd at catalyst.net.nz
Wed Dec 9 02:33:20 UTC 2015
On 05/12/15 14:03, Matt Kassawara wrote:
> The networking guide  contains deployment scenarios  that describe
> the operation of several common OpenStack Networking (neutron)
> architectures including functional configuration examples.
> Currently, the legacy and L3HA scenarios  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
> On the other hand, the provider networks scenarios  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
>  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
> 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.
I'm not crazy about option 1 because I think it could over-complicate
the more simple scenarios.
With respect to option 2, would you be doubling the number of documented
It sounds like the provider network and "Legacy"/L3HA scenarios are
orthogonal enough that they could be separate from each other. I don't
think it is too much to ask of operators to read a couple of sections
and compose them, provided the requirements and prerequisites are clear.
While not specifically pertaining to the re-structure, I will make a
couple of comments about the deploy/scenario sections, if they are being
a. I think these sections are bound to be confusing regardless of how
they are structured or re-structured. Perhaps there should be
high-level comparison of the different scenarios to help operators
decide which scenario best fits their use case. Maybe even a table
b. Does 'Legacy' just mean 'No HA/DVR Routing?' I think that within the
context of OpenStack Networking, it is risky to call anything aside from
Nova Network 'Legacy.' It seems like a 'single L3 agent' scenario is a
perfectly valid use case... It reduces complexity and cost while still
letting users create whatever topology they want. Let me know if I'm
reading this wrong.
>  http://docs.openstack.org/networking-guide/
>  http://docs.openstack.org/networking-guide/deploy.html
>  http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html
>  http://docs.openstack.org/networking-guide/scenario_legacy_lb.html
>  http://docs.openstack.org/networking-guide/scenario_l3ha_ovs.html
>  http://docs.openstack.org/networking-guide/scenario_l3ha_lb.html
>  http://docs.openstack.org/networking-guide/scenario_provider_ovs.html
>  http://docs.openstack.org/networking-guide/scenario_provider_lb.html
>  http://docs.openstack.org/liberty/install-guide-ubuntu/
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
Senior Cloud Engineer
Catalyst IT Limited
+64 4 803 2264
More information about the OpenStack-operators