Your suggested solution uses a single router where all floating IPs will be attached. This will work fine for a single-tenant cloud, but this was not possible to do in a multi-tenant cloud when I tested this a few weeks back.
Perhaps I did not create the router correctly? Is there some type of "shared" metadata that the router needs created with? And just to add input / support to this use-case, a Neutron version of nova-network's FlatDHCP is of great interest to me as well. The main reason is due to the requirement of each tenant router requiring a public IP address. In order for a tenant to get a floating IP on their instance, it costs me one floating IP for their router. I do not like this Floating IP Tax. :) On Mon, Dec 29, 2014 at 2:26 AM, Kevin Benton <[email protected]> wrote: > 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 >
_______________________________________________ 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
