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

Rochelle Grober rochelle.grober at huawei.com
Thu Mar 31 22:17:39 UTC 2016

Cross posting to the Ops ML as one/some of them might have a test cloud like this.


If you respond to this thread, please only respond to the openstack-dev list?

They could use your input;-)


-----Original Message-----
From: Sean Dague [mailto:sean at dague.net] 
Sent: Thursday, March 31, 2016 12:58 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

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

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 Dague

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list