Open Stack

Hi Gal,

I'm sorry for my poor English. Let me try again.

What operator wants to access is several related instances, instead of only
one or one by one. The use case is periodical check and maintain. RELATED
means instance maybe in one subnet, or one network, or one host. The host's
scene is similar to access the docker on the host as you mentioned before.

Via what you mentioned of API, user must ssh an instance and then invoke
API to update the IP address and port, or even create a new PF to access
another one. It will be a nightmare to a VPC operator who owns so many
instances.

In a word, I think the "inside_addr" should be "subnet" or "host".

Hope this is clear enough.

Germy

On Sun, Sep 6, 2015 at 1:05 PM, Gal Sagie <gal.sagie at gmail.com> wrote:

> 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.
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150907/0116679d/attachment.html>