Open Stack

Hi Florian,

I believe your analysis is correct.
However, just because I am a great lover of pedantry, I'd say that
this in not a limitation of the L3 agent. It's more a limitation of
the L3 API.
When updating/creating a router, one can pass a
'external_gateway_info' attribute, whose content are a dict.
Unfortunately the current implementation of the API looks for a
network identifier only, but ideally it should look for a port_id as
well, validate its IP allocation, and then pass those information to
the L3 agent for doing natting (and this is why it was conceived as a
dict originally)

We already have a bug open for allowing the external gateway so
selectively enable or disable default SNAT/DNAT rules
(https://bugs.launchpad.net/quantum/+bug/1121129). Even if this
specific bug might be untargeted from Grizzly, it is my opinion that
it would be valuable to file one and fix it for Grizzly for the issue
you're pointing out. This would be a backward compatible change to the
API, so it will be totally safe (even if we'll probably want to have a
CLI patch too).

Salvatore

On 18 February 2013 13:07, Florian Daniel Otel <florian.otel at gmail.com> wrote:
> Hello all,
>
> Frist, a caveat: This might be as well my limited understanding, but
> despite my efforts I haven't been able to find any better. Please
> advise otherwise.
>
> My problem stems from what I consider a limitation in current L3-agent
> functionality wrt external connectivity.
>
> In particular, the "router-gateway-set" command: AFAICT it
> _automatically_ creates a NAT interface on the external network and
> _automatically_  assigns it an IP address from that space (namely, the
> first one available from the pool of external addresses).
>
> Given the peculiarities of my setup I would like to have more granular
> control over that process. Namely, when defining a NAT gateway to an
> external network I would like to point to a pre-existing device
> interface -- and it's existing IP address--  to assume that role. That
> instead of the above functionality, which _creates_ an interfaces and
> assigns it a (new) IP address.
>
> While I understand that functionality might imply different steps   --
> e.g. ability to "import an underlying device interface as a port" in
> Quantum prior to pointing to that Quantum "port" as the NAT gateway --
> the overall functionality question still stands.
>
> Please advise if:
>
> 1) This can be achieved somehow using existing code.
>
> 2) Is this something that is -- or will be -- addressed somehow. If
> yes, please point me to the appropriate pointers.
>
> Thanks,
>
> Florian
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev