[Openstack-operators] Potential updates to networking guide deployment scenarios
mkassawara at gmail.com
Fri Dec 11 01:31:21 UTC 2015
>From a configuration standpoint, option one only requires adding the public
network to each compute node and some bridge/interface mapping changes.
However, the diagrams and traffic flows become more complex. I could split
the latter into two categories depending on whether a VM attaches to a
public or private network.
Option two requires completely duplicating at least the legacy OVS and
legacy Linux bridge scenarios. The L3HA OVS and L3HA Linux bridge scenarios
also currently only support private networks, but L3HA only applies to
private networks with routers, so L3HA with only public networks makes no
sense to document. In this particular case, mostly because L3HA essentially
builds on the legacy scenarios, we could use option one for them with the
assumption that our audience already understands the legacy concepts.
A high-level comparison makes sense... perhaps using a table? However, we
need to make it as objective as possible. For example, the guide currently
limits the legacy OVS scenario to only support attaching VMs to private
networks, but one can easily add support for attaching VMs to public
networks to any scenario. Also, DVR+L3HA become possible.
Legacy means no HA for private networks and/or routers. We originally
decided to use the word "legacy" to push HA architectures for new
deployments, but a variety of bugs with DVR and L3HA during the first few
release cycles limited adoption. I think we should change it to
conventional, classic, or some other phrasing to indicate lack of HA for
private networks and/or routers.
On Tue, Dec 8, 2015 at 7:33 PM, James Dempsey <jamesd at catalyst.net.nz>
> Hi Matt,
> Commentary in-line.
> 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
> > 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  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
> > 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
> > 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
> > documentation structure that our audience may find difficult to follow.
> > the audience, I would like your input on the usefulness of these
> > 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
> comparing them?
> 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.
> > Thanks,
> > Matt
> >  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_lb.html
> >  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
> James Dempsey
> Senior Cloud Engineer
> Catalyst IT Limited
> +64 4 803 2264
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators