Open Stack

I have looked at the code that you posted. I am concerned that there
are db queries performed inside nested loops.  The approach looks
sound from a functional perspective but I think these loops will run
very slowly and increase pressure on the db.

I tend to think that if a router has an extra route on it then we can
take it at its word that IPs in the scope of the extra route would be
reachable from the router.  In the absence of running a dynamic
routing protocol, that is what is typically done by a router.

Maybe you could use an example to expound on your concerns that we'll
pick the wrong router.  Without a specific example in mind, I tend to
think that we should leave it up to the tenants to avoid the ambiguity
that would get us in to this predicament by using mutually exclusive
subnets on their various networks, especially where there are
different routers involved.

You could use a phased approach where you first hammer out the simpler
approach and follow-on with an enhancement for the more complicated
approach.  It would allow progress to be made on the patch that you
have up and more time to think about the need for the more complex
approach.  You could mark that the first patch partially implements
the blueprint.

Carl



On Thu, Jan 30, 2014 at 6:21 AM, Ofer Barkai <ofer at checkpoint.com> wrote:
> Hi all,
>
> During the implementation of:
> https://blueprints.launchpad.net/neutron/+spec/floating-ip-extra-route
>
> Which suggest allowing assignment of floating IP to internal address
> not directly connected to the router, if there is a route configured on
> the router to the internal address.
>
> In: https://review.openstack.org/55987
>
> There seem to be 2 possible approaches for finding an appropriate
> router for a floating IP assignment, while considering extra routes:
>
> 1. Use the first router that has a route matching the internal address
> which is the target of the floating IP.
>
> 2. Use the first router that has a matching route, _and_ verify that
> there exists a path of connected devices to the network object to
> which the internal address belongs.
>
> The first approach solves the simple case of a gateway on a compute
> hosts that protects an internal network (which is the motivation for
> this enhancement).
>
> However, if the same (or overlapping) addresses are assigned to
> different internal networks, there is a risk that the first approach
> might find the wrong router.
>
> Still, the second approach might force many DB lookups to trace the path from
> the router to the internal network. This overhead might not be
> desirable if the use case does not (at least, initially) appear in the
> real world.
>
> Patch set 6 presents the first, lightweight approach, and Patch set 5
> presents the second, more accurate approach.
>
> I would appreciate the opportunity to get more points of view on this subject.
>
> Thanks,
>
> -Ofer
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev