That's awesome news! I look forward to trying it out in Kilo. On Thu, Mar 19, 2015 at 12:45 PM, Kevin Benton <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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 >>>>> >>>> >>>> >>> >>> >>> -- >>> 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
