<div dir="ltr">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.<div><br></div><div>Let me know if this doesn't work.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 30, 2014 at 9:06 AM, Joe Topjian <span dir="ltr"><<a href="mailto:joe@topjian.net" target="_blank">joe@topjian.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>Perhaps I did not create the router correctly? Is there some type of "shared" metadata that the router needs created with?</div><div><br></div><div>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. :)</div><div><div><br></div><div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, 2014 at 2:26 AM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the setup would be the same as I suggested because it provides<br>
the same isolation properties if I understand the flat-with-floating<br>
topology correctly.<br>
<br>
I'm not sure what topologies will be supported in the current nova net<br>
migration plans, but it seems like it should be possible to have a<br>
automated transition for this one.<br>
<div><div><br>
<br>
<br>
On Mon, Dec 22, 2014 at 8:04 PM, Andrew Bogott <<a href="mailto:abogott@wikimedia.org" target="_blank">abogott@wikimedia.org</a>> wrote:<br>
> Kevin --<br>
><br>
> Thanks for your thoughts; this seems possible, if ugly. My original<br>
> question remains, though: If there is meant to be an upgrade path from<br>
> nova-network (In L, or M, or whenever), what will my use case look like<br>
> after migration? Will it be this same setup that you suggest, or is a<br>
> proper flat-with-floating setup being added to Neutron in order to allow for<br>
> direct migrations?<br>
><br>
> Thanks.<br>
><br>
> -Andrew<br>
><br>
><br>
><br>
> On 12/22/14 5:42 PM, Kevin Benton wrote:<br>
>><br>
>> The shared network would have all of the VMs attached to it and would<br>
>> just be private address space. The shared network would be connected<br>
>> to a virtual router which would be connected to an external network<br>
>> where all of your floating IPs come from. The floating IPs from there<br>
>> would have the allocation, assignment, release features you are<br>
>> looking for.<br>
>><br>
>> However, until the ARP poisoning protection is merged, shared networks<br>
>> aren't very trustworthy across multiple tenants. So you should be able<br>
>> to experiment with the Juno Neutron code in the topology I described<br>
>> above to see if it meets your needs, but I wouldn't suggest a<br>
>> production deployment until the L2 dataplane security features are<br>
>> merged (hopefully during this cycle).<br>
>><br>
>><br>
>> -------------------------<br>
>> | Shared Network | <--- All tenant VMs attach here<br>
>> -------------------------<br>
>> |<br>
>> ------------<br>
>> | Router |<br>
>> ------------<br>
>> |<br>
>> --------------------------<br>
>> | External Network | <--- Floating IPs come from here<br>
>> --------------------------<br>
>><br>
>> On Mon, Dec 22, 2014 at 1:46 AM, Andrew Bogott <<a href="mailto:abogott@wikimedia.org" target="_blank">abogott@wikimedia.org</a>><br>
>> wrote:<br>
>>><br>
>>> On 12/22/14 2:08 PM, Kevin Benton wrote:<br>
>>><br>
>>> Can't you simulate the same topology as the FlatDHCPManager + Floating<br>
>>> IPs<br>
>>> with a shared network attached to a router which is then attached to an<br>
>>> external network?<br>
>>><br>
>>><br>
>>> Mmmmaybe? Floating IP support in nova-network is pretty great<br>
>>> (allocation,<br>
>>> assignment, release, etc.) and allows us shuffle around a small number of<br>
>>> public IPs amongst a much larger number of instances. Your suggestion<br>
>>> doesn't address that, does it? Short of my implementing a bunch of<br>
>>> custom<br>
>>> stuff on my own?<br>
>>><br>
>>> -A<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Sun, Dec 21, 2014 at 7:00 PM, Andrew Bogott <<a href="mailto:abogott@wikimedia.org" target="_blank">abogott@wikimedia.org</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Greetings!<br>
>>>><br>
>>>> I'm about to set up a new cloud, so for the second time this year I'm<br>
>>>> facing the question of Neutron vs. nova-network. In our current setup<br>
>>>> we're<br>
>>>> using nova.network.manager.FlatDHCPManager with floating IPs. This<br>
>>>> config<br>
>>>> has been working fine, and would probably be our first choice for the<br>
>>>> new<br>
>>>> cloud as well.<br>
>>>><br>
>>>> At this point is there any compelling reason for us to switch to<br>
>>>> Neutron?<br>
>>>> My understanding is that the Neutron flat network model still doesn't<br>
>>>> support anything similar to floating IPs, so if we move to Neutron we'll<br>
>>>> need to switch to a subnet-per-tenant model. Is that still correct?<br>
>>>><br>
>>>> I'm puzzled by the statement that " upgrades without instance downtime<br>
>>>> will be available in the Kilo release"[1] -- surely for such a path to<br>
>>>> exist, Kilo/Neutron would need to support all the same use cases as<br>
>>>> nova-network. If that's right and Neutron is right on the verge of<br>
>>>> supporting flat-with-floating then we may just cool our jets and wait to<br>
>>>> build the new cloud until Kilo is released. I have no particular reason<br>
>>>> to<br>
>>>> prefer Neutron, but I'd like to avoid betting on a horse right before<br>
>>>> it's<br>
>>>> put down :)<br>
>>>><br>
>>>> Thanks!<br>
>>>><br>
>>>> -Andrew<br>
>>>><br>
>>>> [1]<br>
>>>><br>
>>>> <a href="http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html" target="_blank">http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html</a><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Mailing list:<br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>>>> Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
>>>> Unsubscribe :<br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
>>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Kevin Benton<br>
>>><br>
>>><br>
>><br>
>><br>
><br>
<br>
<br>
<br>
--<br>
Kevin Benton<br>
<br>
_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>