Open Stack

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 <blak111 at 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 <joe at 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 <blak111 at 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 <abogott at 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 <abogott at 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 <
>>> abogott at 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 at 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 at lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>
>>
>
>
> --
> Kevin Benton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150116/b358109a/attachment.html>