Open Stack

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 <joe at 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 <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
>>
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150319/670b1a96/attachment.html>