Open Stack

That's awesome news! I look forward to trying it out in Kilo.

On Thu, Mar 19, 2015 at 12:45 PM, Kevin Benton <blak111 at gmail.com> 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 <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/bd6c4b56/attachment.html>