[openstack-dev] Floating IPs and Public IPs are not equivalent

Kevin Benton kevin at benton.pub
Fri Apr 1 22:05:57 UTC 2016


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 <sean at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160401/c6487dc2/attachment.html>


More information about the OpenStack-dev mailing list