Sorry about the long delay on this. The floating IP issue is just a Horizon bug.[1]
Once that's fixed and once we have some arp spoofing protection, that should be on par with nova-network's FlatDHCP. 1. https://review.openstack.org/#/c/163728/ On Fri, Jan 16, 2015 at 7:12 AM, Joe Topjian <j...@topjian.net> wrote: > Tenants can launch on the shared network. The issue is with floating IP > addresses: when the tenant goes to associate a floating IP, they see "No > ports available" (just tested with Juno). > > Is there a setting or attribute that needs to be applied to the admin's > router to make it shared? > > If they were allowed to attach a floating IP to the admin's router, then > this setup is essentially on par with nova-network's FlatDHCP. > > On Thu, Jan 15, 2015 at 11:16 PM, Kevin Benton <blak...@gmail.com> wrote: > >> You should be able to create a router under the same admin tenant as the >> external network and attach it to a shared network also owned by the admin >> tenant. Then other tenants would just attach their VMs to the shared >> network. >> >> Let me know if this doesn't work. >> >> On Tue, Dec 30, 2014 at 9:06 AM, Joe Topjian <j...@topjian.net> wrote: >> >>> 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 <blak...@gmail.com> 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 <abog...@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 < >>>> abog...@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 < >>>> abog...@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@lists.openstack.org >>>> >>>> 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 : openstack@lists.openstack.org >>>> 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 : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
