Open Stack

I think the setup would be the same as I suggested because it provides
the same isolation properties if I understand the flat-with-floating
topology correctly.

I'm not sure what topologies will be supported in the current nova net
migration plans, but it seems like it should be possible to have a
automated transition for this one.



On Mon, Dec 22, 2014 at 8:04 PM, Andrew Bogott <abogott at wikimedia.org> wrote:
> 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
>>>
>>>
>>
>>
>



-- 
Kevin Benton