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 >
_______________________________________________ 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
