Open Stack

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/20150115/dc509e80/attachment.html>