Open Stack

Hi Germy,

I am not sure i understand what you mean, can you please explain it
further?

Thanks
Gal.

On Sun, Sep 6, 2015 at 5:39 AM, Germy Lure <germy.lure at gmail.com> wrote:

> Hi, Gal
>
> Thank you for bringing this up. But I have some suggestions for the API.
>
> An operator or some other component wants to reach several VMs related NOT
> only one or one by one. Here, RELATED means that the VMs are in one subnet
> or network or a host(similar to reaching dockers on a host).
>
> Via the API you mentioned, user must ssh one VM and update even delete and
> add PF to ssh another. To a VPC(with 20 subnets?) admin, it's totally a
> nightmare.
>
> Germy
>
>
> On Wed, Sep 2, 2015 at 1:59 PM, Gal Sagie <gal.sagie at gmail.com> wrote:
>
>> Hello All,
>>
>> I have searched and found many past efforts to implement port forwarding
>> in Neutron.
>> I have found two incomplete blueprints [1], [2] and an abandoned patch
>> [3].
>>
>> There is even a project in Stackforge [4], [5] that claims
>> to implement this, but the L3 parts in it seems older then current master.
>>
>> I have recently came across this requirement for various use cases, one
>> of them is
>> providing feature compliance with Docker port-mapping feature (for
>> Kuryr), and saving floating
>> IP's space.
>> There has been many discussions in the past that require this feature, so
>> i assume
>> there is a demand to make this formal, just a small examples [6], [7],
>> [8], [9]
>>
>> The idea in a nutshell is to support port forwarding (TCP/UDP ports) on
>> the external router
>> leg from the public network to internal ports, so user can use one
>> Floating IP (the external
>> gateway router interface IP) and reach different internal ports depending
>> on the port numbers.
>> This should happen on the network node (and can also be leveraged for
>> security reasons).
>>
>> I think that the POC implementation in the Stackforge project shows that
>> this needs to be
>> implemented inside the L3 parts of the current reference implementation,
>> it will be hard
>> to maintain something like that in an external repository.
>> (I also think that the API/DB extensions should be close to the current
>> L3 reference
>> implementation)
>>
>> I would like to renew the efforts on this feature and propose a RFE and a
>> spec for this to the
>> next release, any comments/ideas/thoughts are welcome.
>> And of course if any of the people interested or any of the people that
>> worked on this before
>> want to join the effort, you are more then welcome to join and comment.
>>
>> Thanks
>> Gal.
>>
>> [1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding
>> [2] https://blueprints.launchpad.net/neutron/+spec/fip-portforwarding
>> [3] https://review.openstack.org/#/c/60512/
>> [4] https://github.com/stackforge/networking-portforwarding
>> [5] https://review.openstack.org/#/q/port+forwarding,n,z
>>
>> [6]
>> https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/
>> [7] http://www.gossamer-threads.com/lists/openstack/dev/34307
>> [8]
>> http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-for-router-td46639.html
>> [9]
>> http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-from-gateway-to-internal-hosts-td32410.html
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards ,

The G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150906/8308ebb3/attachment.html>