Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
Ok. I'll bite. :) Security is like a castle. More walls provide more protection. One outer wall only is something that tends to bite folks because they assume the first wall won't ever be breached. Nat is one type of wall. Not to be used by itself but provides additional protection. For example, I witnessed an organization recently misconfigure their firewall rules by accedent and all of the private servers were suddenly accessible from the internet. If these same machines were on private nated space, the failure in the firewall wall, would have not immediately exposed all of the private servers to unexpected attack. They would be protected by the fact that the ip's weren't routeable. Nat's just another tool for the toolbox. its not good, or evil. Its useful though, so stop trying to kill it. Thanks, Kevin From: Salvatore Orlando [salv.orla...@gmail.com] Sent: Wednesday, April 06, 2016 1:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Floating IPs and Public IPs are not equivalent Hey! This sounds like bike-shedding & yak-shaving... totally my thing! It is true that the Neutron model currently kind of forces a two-level topology, with the external network being a sort of special case. Regardless, this does not mean you cannot assign directly public IPs to your instances - Neutron routers also work without NAT. Shall we start a discussion on the evils of NAT now? To me is one of those things like landline telephones. You don't really need them, you know how to do without them, but for some reason you keep using them and perceiving them as a fundamental service. As for the issue Kevin pointed out, that's a limitation of the current reference implementation that if overcome will probably simplify the Neutron control plane as well. Salvatore On 2 April 2016 at 00:05, Kevin Benton mailto:ke...@benton.pub>> wrote: 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 mailto:s...@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-requ...@lists.openstack.org?subject:unsubscribe<http://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://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
Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
Hey! This sounds like bike-shedding & yak-shaving... totally my thing! It is true that the Neutron model currently kind of forces a two-level topology, with the external network being a sort of special case. Regardless, this does not mean you cannot assign directly public IPs to your instances - Neutron routers also work without NAT. Shall we start a discussion on the evils of NAT now? To me is one of those things like landline telephones. You don't really need them, you know how to do without them, but for some reason you keep using them and perceiving them as a fundamental service. As for the issue Kevin pointed out, that's a limitation of the current reference implementation that if overcome will probably simplify the Neutron control plane as well. Salvatore On 2 April 2016 at 00:05, Kevin Benton wrote: > 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 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-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
Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
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 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-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
Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
Or if you don't like floating IPs, it means you can have floating IPs available to only one tenant you dislike. :) On Fri, Apr 1, 2016 at 11:39 AM, Monty Taylor 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
Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
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 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
Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
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
Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
And with external rbac in mitaka, you can finally have private floating ip's. :) Thanks, Kevin 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
Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
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 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
Re: [openstack-dev] Floating IPs and Public IPs are not equivalent
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
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-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
