I probably missed something but... Is the direct attached public IP available in devstack?
I'm not speaking about the default configuration but just the feature. -- Jean-Daniel Bonnetot http://www.ovh.com @pilgrimstack > Le 1 avr. 2016 à 00:17, Rochelle Grober <rochelle.gro...@huawei.com> a écrit : > > Cross posting to the Ops ML as one/some of them might have a test cloud like > this. > > Operators: > > If you respond to this thread, please only respond to the openstack-dev list? > > They could use your input;-) > > --Rocky > > -----Original Message----- > From: Sean Dague [mailto:s...@dague.net] > Sent: Thursday, March 31, 2016 12:58 PM > To: openstack-dev@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 > 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 __________________________________________________________________________ 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