Open Stack

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 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
--