Open Stack

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 <kevin at 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 <sean at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160406/0eeeced3/attachment.html>