<div dir="ltr">Or if you don't like floating IPs, it means you can have floating IPs available to only one tenant you dislike. :)</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 1, 2016 at 11:39 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/01/2016 12:00 PM, Fox, Kevin M wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And with external rbac in mitaka, you can finally have private floating<br>
ip's. :)<br>
</blockquote>
<br></span>
Wha. I mean.<br>
<br>
My face. It just fell off.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
------------------------------------------------------------------------<br>
*From:* Monty Taylor<br>
*Sent:* Thursday, March 31, 2016 10:23:22 AM<br>
*To:* OpenStack Development Mailing List (not for usage questions)<br>
*Subject:* [openstack-dev] Floating IPs and Public IPs are not equivalent<div><div class="h5"><br>
<br>
Just a friendly reminder to everyone - floating IPs are not synonymous<br>
with Public IPs in OpenStack.<br>
<br>
The most common (and growing, thank you to the beta of the new<br>
Dreamcompute cloud) configuration for Public Clouds is directly assign<br>
public IPs to VMs without requiring a user to create a floating IP.<br>
<br>
I have heard that the require-floating-ip model is very common for<br>
private clouds. While I find that even stranger, as the need to run NAT<br>
inside of another NAT is bizarre, it is what it is.<br>
<br>
Both models are common enough that pretty much anything that wants to<br>
consume OpenStack VMs needs to account for both possibilities.<br>
<br>
It would be really great if we could get the default config in devstack<br>
to be to have a shared direct-attached network that can also have a<br>
router attached to it and provider floating ips, since that scenario<br>
actually allows interacting with both models (and is actually the most<br>
common config across the OpenStack public clouds)<br>
<br>
Monty<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>