I wish it was that easy... the external network currently only attaches to the network node.
On Sat, Dec 5, 2015 at 12:15 PM, Kevin Benton <blak...@gmail.com> wrote: > 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? > > "If you want to allow tenants to attach directly to these networks as > well, continue reading." > > Then it has one step where you mark the network as 'shared' as well and > it's done. ;) > > On Fri, Dec 4, 2015 at 5:03 PM, Matt Kassawara <mkassaw...@gmail.com> > 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. >> >> 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 >> >> > > > -- > Kevin Benton >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
