The main barrier to this is that we need to stop using the 'external_network_bridge = br-ex' option for the L3 agent and define a bridge mapping on the L2 agent. Otherwise the external network is treated as a special case and the VMs won't actually be able to get wired into the external network.
On Thu, Mar 31, 2016 at 12:58 PM, Sean Dague <s...@dague.net> wrote: > On 03/31/2016 01:23 PM, Monty Taylor wrote: > > Just a friendly reminder to everyone - floating IPs are not synonymous > > with Public IPs in OpenStack. > > > > The most common (and growing, thank you to the beta of the new > > Dreamcompute cloud) configuration for Public Clouds is directly assign > > public IPs to VMs without requiring a user to create a floating IP. > > > > I have heard that the require-floating-ip model is very common for > > private clouds. While I find that even stranger, as the need to run NAT > > inside of another NAT is bizarre, it is what it is. > > > > Both models are common enough that pretty much anything that wants to > > consume OpenStack VMs needs to account for both possibilities. > > > > It would be really great if we could get the default config in devstack > > to be to have a shared direct-attached network that can also have a > > router attached to it and provider floating ips, since that scenario > > actually allows interacting with both models (and is actually the most > > common config across the OpenStack public clouds) > > If someone has the the pattern for what that config looks like, > especially if it could work on single interface machines, that would be > great. > > The current defaults in devstack are mostly there for legacy reasons > (and because they work everywhere), and for activation energy to getting > a new robust work everywhere setup. > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
