<div dir="ltr">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?<div><br></div><div>"If you want to allow tenants to attach directly to these networks as well, continue reading."</div><div><br></div><div>Then it has one step where you mark the network as 'shared' as well and it's done. ;)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 4, 2015 at 5:03 PM, Matt Kassawara <span dir="ltr"><<a href="mailto:mkassawara@gmail.com" target="_blank">mkassawara@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The networking guide [1] contains deployment scenarios [2] that describe the operation of several common OpenStack Networking (neutron) architectures including functional configuration examples.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>1) Add support for attaching VMs to public networks to the existing scenarios.</div><div>2) Create additional scenarios that support attaching VMs to both public and private networks.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Matt</div><div><br></div><div>[1] <a href="http://docs.openstack.org/networking-guide/" target="_blank">http://docs.openstack.org/networking-guide/</a></div><div>[2] <a href="http://docs.openstack.org/networking-guide/deploy.html" target="_blank">http://docs.openstack.org/networking-guide/deploy.html</a></div><div>[3] <a href="http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html" target="_blank">http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html</a></div><div>[4] <a href="http://docs.openstack.org/networking-guide/scenario_legacy_lb.html" target="_blank">http://docs.openstack.org/networking-guide/scenario_legacy_lb.html</a></div><div>[5] <a href="http://docs.openstack.org/networking-guide/scenario_l3ha_ovs.html" target="_blank">http://docs.openstack.org/networking-guide/scenario_l3ha_ovs.html</a></div><div>[6] <a href="http://docs.openstack.org/networking-guide/scenario_l3ha_lb.html" target="_blank">http://docs.openstack.org/networking-guide/scenario_l3ha_lb.html</a></div><div>[7] <a href="http://docs.openstack.org/networking-guide/scenario_provider_ovs.html" target="_blank">http://docs.openstack.org/networking-guide/scenario_provider_ovs.html</a></div><div>[8] <a href="http://docs.openstack.org/networking-guide/scenario_provider_lb.html" target="_blank">http://docs.openstack.org/networking-guide/scenario_provider_lb.html</a></div><div>[9] <a href="http://docs.openstack.org/liberty/install-guide-ubuntu/" target="_blank">http://docs.openstack.org/liberty/install-guide-ubuntu/</a></div></div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>