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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 : [email protected] >>>> Unsubscribe : >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>>> >>> >>> >>> -- >>> Kevin Benton >>> >>> >> >> > -- Kevin Benton _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
