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 <[email protected]> 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 <[email protected]> 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: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best Regards , The G.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
