Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141230/322ac59d/attachment.html>