Hi Matt, Commentary in-line.
On 05/12/15 14:03, Matt Kassawara 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. > 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 scenarios? 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 updated... 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. Cheers, James > 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@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
