Open Stack

Hi Germy,

Yes i understand now.
What you request is an enahncment to the API to be able to assing these
port forwarding rules in bulks per subnet.
I will make sure to mention this in the spec that i am writing for this.

Thanks!
Gal.


On Tue, Sep 8, 2015 at 10:33 AM, Germy Lure <germy.lure at gmail.com> wrote:

> Hi Gal,
>
> Thank you for your explanation.
> As you mentioned, PF is a way of reusing floating IP to access several
> Neutron ports. I agree with your point of view completely.
> Let me extend your example to explain where I was going.
> T1 has 20 subnets behind a router, and one of them is 10.0.0.0/24 named
> s1. There are 100 VMs named VM1~VM100 in the subnet s1 and T1 wants to
> update the same file(or something else) in those VMs. Let's have a look how
> will T1 do it.
>
> T1 invokes Neutron API to create a port-mapping for VM1(Maybe that will be
> did by operator)
> For example :  172.20.20.10:4001  =>  10.0.0.1:80
> And then T1 does the update task via 172.20.20.10:4001.
>
> Now for the VM2,VM3,...VM100, T1 must repeat the steps above with
> different ports. And T1 must clean those records(100 records in DB) after
> accessing. That's badly, I think.
> Note that T1 still has 19 subnets to be dealt with. That's a nightmare to
> T1.
> To PaaS, SaaS, that also is a big trouble.
>
> So, can we do it like this?
> T1 invokes Neutron API one time for s1(not VM1), and Neutron setups a
> group of port-mapping relation. For example:
> 172.20.20.10:4001  =>  10.0.0.1:80
> 172.20.20.10:4002  =>  10.0.0.2:80
> 172.20.20.10:4003  =>  10.0.0.3:80
> ......                                   ......
> 172.20.20.10:4100  =>  10.0.0.100:80
> Now T1 just needs focus on his/her business work not PF.
>
> We just store one record in Neutron DB for such one time API invoking. For
> the single VM scene, we can specific private IP range instead of subnet.
> For example, 10.0.0.1 to 10.0.0.3. The mapped ports(like 4001,4002...) can
> be returned in the response body, for example, 4001 to 4003, also can just
> return a base number(4000) and upper layer rework it. For example, 4000+1,
> where 1 is the last number in the private IP address of VM1.
>
> Forgive my poor E.
> Hope that's clear enough and i am happy to discuss it further if necessary.
>
> Germy
>
>
> On Tue, Sep 8, 2015 at 1:58 PM, Gal Sagie <gal.sagie at gmail.com> wrote:
>
>> Hi Germy,
>>
>> Port forwarding the way i see it, is a way of reusing the same floating
>> ip to access several different Neutron ports (VM's , Containers)
>> So for example if we have floating IP 172.20.20.10 , we can assign
>> 172.20.20.10:4001 to VM1 and 172.20.20.10:4002 to VM2 (which are behind
>> that same router
>> which has an external gw).
>> The user use the same IP but according to the tcp/udp port Neutron
>> performs mapping in the virtual router namespace to the private IP and
>> possibly to a different port
>> that is running on that instance for example port 80
>>
>> So for example if we have two VM's with private IP's 10.0.0.1 and
>> 10.0.0.2 and we have a floating ip assigned to the router of 172.20.20.10
>> with port forwarding we can build the following mapping:
>>
>> 172.20.20.10:4001  =>  10.0.0.1:80
>> 172.20.20.10:4002  =>  10.0.0.2:80
>>
>> And this is only from the Neutron API, this feature is usefull when you
>> offer PaaS, SaaS and have an automated framework that calls the API
>> to allocate these "client ports"
>>
>> I am not sure why you think the operator will need to ssh the instances,
>> the operator just needs to build the mapping of <floating_ip, port>  to the
>> instance private IP.
>> Of course keep in mind that we didnt yet discuss full API details but its
>> going to be something like that (at least the way i see it)
>>
>> Hope thats explains it.
>>
>> Gal.
>>
>> On Mon, Sep 7, 2015 at 5:21 AM, Germy Lure <germy.lure at gmail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>
>>
>
> __________________________________________________________________________
> 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/20150908/0c67b620/attachment.html>