Sean, I can tell you how the configuration should work. Sean Collins and I have collaborated quite a bit on how to fix the DevStack networking problems... mostly by replacing the legacy neutron bits with something a bit more flexible and less crufty.
On Fri, Apr 1, 2016 at 12:39 PM, Monty Taylor <mord...@inaugust.com> wrote: > On 04/01/2016 12:00 PM, Fox, Kevin M wrote: > >> And with external rbac in mitaka, you can finally have private floating >> ip's. :) >> > > Wha. I mean. > > My face. It just fell off. > > ------------------------------------------------------------------------ >> *From:* Monty Taylor >> *Sent:* Thursday, March 31, 2016 10:23:22 AM >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* [openstack-dev] Floating IPs and Public IPs are not equivalent >> >> >> 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) >> >> Monty >> >> __________________________________________________________________________ >> 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 >> >> > > __________________________________________________________________________ > 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
