Open Stack

Kevin --

Thanks for your thoughts; this seems possible, if ugly.  My original 
question remains, though:  If there is meant to be an upgrade path from 
nova-network (In L, or M, or whenever), what will my use case look like 
after migration?  Will it be this same setup that you suggest, or is a 
proper flat-with-floating setup being added to Neutron in order to allow 
for direct migrations?

Thanks.

-Andrew


On 12/22/14 5:42 PM, Kevin Benton wrote:
> 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
>>
>>
>
>