Open Stack

The shared network would have all of the VMs attached to it and would
just be private address space. The shared network would be connected
to a virtual router which would be connected to an external network
where all of your floating IPs come from. The floating IPs from there
would have the allocation, assignment, release features you are
looking for.

However, until the ARP poisoning protection is merged, shared networks
aren't very trustworthy across multiple tenants. So you should be able
to experiment with the Juno Neutron code in the topology I described
above to see if it meets your needs, but I wouldn't suggest a
production deployment until the L2 dataplane security features are
merged (hopefully during this cycle).


-------------------------
| Shared Network |   <--- All tenant VMs attach here
-------------------------
             |
       ------------
       | Router |
       ------------
             |
--------------------------
| External Network |    <--- Floating IPs come from here
--------------------------

On Mon, Dec 22, 2014 at 1:46 AM, Andrew Bogott <abogott at wikimedia.org> wrote:
> On 12/22/14 2:08 PM, Kevin Benton wrote:
>
> Can't you simulate the same topology as the FlatDHCPManager + Floating IPs
> with a shared network attached to a router which is then attached to an
> external network?
>
>
> Mmmmaybe?  Floating IP support in nova-network is pretty great (allocation,
> assignment, release, etc.) and allows us shuffle around a small number of
> public IPs amongst a much larger number of instances.  Your suggestion
> doesn't address that, does it?  Short of my implementing a bunch of custom
> stuff on my own?
>
> -A
>
>
>
>
> On Sun, Dec 21, 2014 at 7:00 PM, Andrew Bogott <abogott at wikimedia.org>
> wrote:
>>
>> Greetings!
>>
>> I'm about to set up a new cloud, so for the second time this year I'm
>> facing the question of Neutron vs. nova-network.  In our current setup we're
>> using nova.network.manager.FlatDHCPManager with floating IPs.  This config
>> has been working fine, and would probably be our first choice for the new
>> cloud as well.
>>
>> At this point is there any compelling reason for us to switch to Neutron?
>> My understanding is that the Neutron flat network model still doesn't
>> support anything similar to floating IPs, so if we move to Neutron we'll
>> need to switch to a subnet-per-tenant model.  Is that still correct?
>>
>> I'm puzzled by the statement that " upgrades without instance downtime
>> will be available in the Kilo release"[1] -- surely for such a path to
>> exist, Kilo/Neutron would need to support all the same use cases as
>> nova-network.  If that's right and Neutron is right on the verge of
>> supporting flat-with-floating then we may just cool our jets and wait to
>> build the new cloud until Kilo is released.  I have no particular reason to
>> prefer Neutron, but I'd like to avoid betting on a horse right before it's
>> put down :)
>>
>> Thanks!
>>
>> -Andrew
>>
>> [1]
>> http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html
>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
>
>
> --
> Kevin Benton
>
>



-- 
Kevin Benton