14:00:26 <slaweq> #startmeeting neutron_drivers 14:00:27 <openstack> Meeting started Fri Jul 3 14:00:26 2020 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:28 <slaweq> hi 14:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:31 <openstack> The meeting name has been set to 'neutron_drivers' 14:01:05 <slaweq> rafaelweingartne: hi, yes we now have neutron drivers meeting 14:01:22 <rafaelweingartne> Awesome, thanks. 14:01:24 <amotoki> hi 14:01:32 <ralonsoh> hi 14:01:33 <slaweq> but I'm not sure if we will have quorum today as many people in US have got holiday today 14:01:43 <rafaelweingartne> I see 14:01:54 <slaweq> I know that haleyb and mlavalle will not be here today 14:02:07 <amotoki> sorry for missing the last two meetings. I was too sleepy and felt asleep..... 14:02:14 <slaweq> amotoki: np 14:02:17 <ralonsoh> neither njohnston I think... 14:02:24 <slaweq> ahh, ok 14:02:33 <slaweq> so lets wait few minutes for yamamoto 14:02:45 <slaweq> if he will not show up, we will not have quorum 14:03:02 <slaweq> btw. please welcome our new driver: ralonsoh :) 14:03:05 <rafaelweingartne> I worked with Pedro, in the port-range extension for Neutron floating IPs, and I came here to see if you guys will have questions for us during the meeting 14:03:06 <slaweq> welcome in the team 14:03:09 <ralonsoh> thanks !! 14:03:35 <amotoki> ralonsoh: welcome :) 14:03:40 <ralonsoh> amotoki, thanks a lot 14:08:15 <slaweq> I think we will have yamamoto on the meeting :) 14:08:26 <slaweq> he just joined channel 14:08:33 <yamamoto> hi 14:08:37 <slaweq> hi 14:08:47 <slaweq> ok, so we have 4 of us which is quorum 14:08:57 <slaweq> I think we can move on 14:09:04 <slaweq> #topic RFEs 14:09:11 <slaweq> we have 1 rfe for today 14:09:18 <slaweq> https://bugs.launchpad.net/neutron/+bug/1885921 14:09:18 <openstack> Launchpad bug 1885921 in neutron "[RFE][floatingip port_forwarding] Add port ranges" [Wishlist,New] - Assigned to Pedro Henrique Pereira Martins (pedrohpmartins) 14:09:40 <slaweq> and we have rafaelweingartne who is knows this rfe :) 14:10:25 <rafaelweingartne> exactly, we implemented it internally on top of rocky, and now we would like to contribute back to the community 14:11:36 <slaweq> my question is: what is the real problem which You are trying to solve? is number of port forwarding entries now such big issue? 14:12:33 <rafaelweingartne> we would like to be able to create/use ranges 14:12:57 <rafaelweingartne> for instance right now (without that PR), we are only able to create NAT mappings one by one 14:13:14 <rafaelweingartne> however, that is cumbersome if we need to map ranges 14:13:43 <rafaelweingartne> such as all ten ports from 80-90 from a public IP to an internal IP 14:14:08 <rafaelweingartne> iptables already accepts ranges, and we would just expose such feature 14:14:23 <rafaelweingartne> network operators are very used to this use case 14:14:41 <amotoki> What is a real usecase of using a port range? 14:15:11 <amotoki> I think it is not so common to use a consecutive range of listened ports. 14:15:34 <amotoki> I might be missing something though 14:15:36 <slaweq> amotoki: that is exactly what I think also 14:15:48 <slaweq> that's why I asked about real problem here 14:16:15 <rafaelweingartne> I am not a network guy myself, but for instance, we already have that in PROD, and there are people using 14:16:22 <rafaelweingartne> externalizing ports by range 14:16:39 <rafaelweingartne> the network engineers came with this requirement 14:16:50 <rafaelweingartne> it seems that for some use cases they have, this facilitate things 14:17:03 <rafaelweingartne> I do not see a problem to be flexible with that 14:19:08 <rafaelweingartne> for instance, for passive FTP 14:19:17 <rafaelweingartne> we would normally use a port range 14:19:48 <amotoki> we am not necessarily against the proposal. we can do it but we just would like to know real usecase where this is needed. 14:19:50 <rafaelweingartne> 55536-55635, without that proposal, we would need to enter 100 API calls to open all of these ports 14:20:31 <rafaelweingartne> Basically, all appliation that needs a range of ports to be open, we would need to open this range with one rule for each port, which is not ideal 14:22:20 <ralonsoh> I would agree with this proposal if, in case of being approved, the port range could be defined in a flexible way 14:22:40 <ralonsoh> for example, "10-23,31-50,100-120" 14:22:47 <rafaelweingartne> I am not sure what you mean by flexible 14:22:53 <rafaelweingartne> but that is exactly what we did 14:23:10 <rafaelweingartne> an internal range, and an external range 14:23:14 <ralonsoh> I only saw one interval in the examples 14:23:16 <rafaelweingartne> and the ranges do not need to be the same 14:23:20 <slaweq> ralonsoh: I'm not sure if that isn't too much 14:23:25 <rafaelweingartne> they only need to match in size 14:23:39 <ralonsoh> slaweq, but that's the case you were talking about 14:24:00 <ralonsoh> the port ranges could not be sequential 14:24:09 <ralonsoh> just my opinion 14:24:21 <rafaelweingartne> what do you mean by that? 14:24:56 <ralonsoh> nevermind 14:24:58 <rafaelweingartne> I mean, we see a range as [x-y] 14:25:08 <rafaelweingartne> where we take everything in between inclusing the X and Y 14:26:54 <slaweq> what in case if e.g. user define first forwarding for range 10-20 and later he will want to remove port 15 from it and use in in different PF? 14:27:12 <slaweq> with Your proposed change it will be more complicated to do than it is now 14:27:15 <rafaelweingartne> not possible 14:27:37 <rafaelweingartne> ah, yes, but what is the chance of that happening? 14:27:46 <slaweq> idk 14:28:05 <rafaelweingartne> applications normally have pre-defined ranges to work with 14:28:38 <rafaelweingartne> and even if that happens, we implemented an update 14:28:41 <slaweq> and also idk what is the chance that someone will need to define pf for range with e.g. 100 consequtive ports 14:28:48 <rafaelweingartne> so update the first one to be 10-14, 14:28:52 <rafaelweingartne> then you use the 15 to something else 14:29:02 <rafaelweingartne> and then you can create a new one between 16-20 14:29:05 <amotoki> rafaelweingartne: but the current FIP port forwarding API allows PUT operation. 14:29:20 <rafaelweingartne> for one-one 14:29:43 <rafaelweingartne> the whole problem is only allowing users to create NAT rule with a single port 14:30:08 <rafaelweingartne> if you look at other networking solutions, whenever they deal with NAT, they allow ranges 14:30:26 <rafaelweingartne> I do not see any complications to add such feature 14:31:18 <rafaelweingartne> The key here is to allow 14:31:21 <rafaelweingartne> not force users 14:31:29 <rafaelweingartne> if they still want to use 1-1, that is still fine 14:31:52 <rafaelweingartne> however, if the user wants to map a range to another range, why not allow such operation? 14:33:22 <yamamoto> i used to have range configuration like that for one of my routers. i can understand it's sometimes useful. 14:33:47 <rafaelweingartne> it is, our users already use in production 14:34:10 <slaweq> I'm generally fine with this proposal, even if I personally don't have such usecases in mind but others may have :) 14:34:12 <rafaelweingartne> I am a developer, and I see your point guys, I was also skeptical at the begining, but somehow the users do use it 14:34:32 <slaweq> but as it require API and DB schema changes, I would like to have spec for that first 14:35:08 <rafaelweingartne> you mean the pull request? 14:35:18 <rafaelweingartne> or, do we need another spec just for the DB changes? 14:35:37 <ralonsoh> no, for the whole feature 14:35:52 <ralonsoh> explaining the DB changes, API extension, etc 14:36:12 <ralonsoh> slaweq, pforwarding now admits to change the external and internal ports 14:36:15 <rafaelweingartne> inst that what we have here https://bugs.launchpad.net/neutron/+bug/1885921? 14:36:15 <openstack> Launchpad bug 1885921 in neutron "[RFE][floatingip port_forwarding] Add port ranges" [Wishlist,New] - Assigned to Pedro Henrique Pereira Martins (pedrohpmartins) 14:36:28 <rafaelweingartne> do we need to list something else? 14:36:46 <slaweq> rafaelweingartne: You need to propose spec with details of the change to https://github.com/openstack/neutron-specs 14:37:19 <rafaelweingartne> hmm 14:37:30 <slaweq> ralonsoh: yes but is that problem? 14:37:46 <amotoki> RFE mainly discusses the need for the feature, and more discussion on implementation around API/DB and so on happens in the spec. 14:38:03 <rafaelweingartne> so besides that document we created in launch pad, we also need to write it down 14:38:18 <rafaelweingartne> so, what do you need? API inputs/output, validations, new DB schema 14:38:18 <amotoki> at least, in the RFE bug description, we have a room to discuss what the API and DB schema should be. 14:38:24 <rafaelweingartne> something else? 14:39:10 <slaweq> rafaelweingartne: maybe some testing plan for this new feature 14:39:27 <rafaelweingartne> we covered the code with unit tests 14:39:27 <amotoki> launchpad bug does not allows us to discuss line-by-line, so we would like to see a spec for detail. doesn't it make sense to you? 14:39:33 <rafaelweingartne> I mean, all of the changes we did 14:39:44 <rafaelweingartne> yes, it does 14:40:10 <rafaelweingartne> do you need some other testing plan? besides unit testing everything? 14:40:22 <slaweq> ok, so I'm personally ok to approve this rfe as an idea and continue discussion about api/db changes in the spec review 14:40:42 <amotoki> I also dropped one small question in https://bugs.launchpad.net/neutron/+bug/1885921/comments/2 14:40:42 <openstack> Launchpad bug 1885921 in neutron "[RFE][floatingip port_forwarding] Add port ranges" [Wishlist,New] - Assigned to Pedro Henrique Pereira Martins (pedrohpmartins) 14:40:44 <slaweq> rafaelweingartne: would be good if You could propose some tempest API/scenario tests also 14:40:54 <rafaelweingartne> ok 14:40:55 <amotoki> I am not sure N-1 port mapping works 14:40:56 <rafaelweingartne> we will do that then 14:41:05 <amotoki> but this can be dsicussed in the spec if we approve it. 14:41:52 <slaweq> N-1? 14:42:15 <slaweq> I thought that we are talking about N-N mapping only 14:42:20 <amotoki> the RFE description says "N(external port[s]) to 1 (internal port)" is allowed. 14:42:23 <slaweq> where I missed this proposal of N-1? 14:42:28 <amotoki> I don't understand how it works. 14:42:39 <slaweq> amotoki: ahh, right 14:42:43 <slaweq> I see it now 14:42:49 <slaweq> in validations part 14:42:58 <slaweq> rafaelweingartne: can You explain that? 14:43:33 <rafaelweingartne> Yes 14:44:38 <rafaelweingartne> so, we can have an application listening in a single port internally, but for some reason, the user/dev/operator wants to expose it via multiple external ports. This might happen for instance, when someone starts exporting something in a port e.g. 8080 14:44:54 <rafaelweingartne> and then we also want port 80 to expose the same application 14:45:10 <rafaelweingartne> then we have multiple external ports that direct the traffic to the same internal application port 14:45:33 <rafaelweingartne> it was used to maitain compatibility with some legacy system 14:46:09 <amotoki> rafaelweingartne: how does it work when an internal port starts a connection? 14:46:23 <rafaelweingartne> what do you mean? 14:46:49 <amotoki> rafaelweingartne: from the nature of floating IP, both intrenal and external sides can start a connection. 14:47:18 <rafaelweingartne> hmm 14:47:35 <slaweq> amotoki: is it working like that now with PF 1:1? 14:47:36 <amotoki> or is it okay to consider listened port case? 14:47:37 <rafaelweingartne> ports do not actually start connection, but applications 14:47:37 <slaweq> I'm not sure 14:48:16 <amotoki> slaweq: I need to check more detail around iptables behavior 14:48:25 <rafaelweingartne> all that the current NAT configurations do is to create iptables rules to forward packets 14:48:55 <slaweq> amotoki: sure, but I think this can be discussed in the spec review 14:48:59 <rafaelweingartne> the only thing that we are doing is just making it flexible that configurations, similarly to what iptable already allows you to do. 14:49:17 <rafaelweingartne> also, they are forwarding incoming packets 14:49:29 <rafaelweingartne> from what I remember they are not touching the outgoing packets 14:49:35 <rafaelweingartne> unless, of course, the ACLs 14:49:41 <rafaelweingartne> but that is something else 14:51:13 <rafaelweingartne> So, to sumarise, we will propose the spect at https://github.com/openstack/neutron-specs. The spec will have the context (problem description), the APIs, APIs' inputs and outputs, validations, new db schemas, and the tempest scenarios. 14:51:25 <rafaelweingartne> Is that what you guys would like to see? 14:51:29 <slaweq> rafaelweingartne: yes 14:51:35 <rafaelweingartne> ok, we will do that then 14:51:44 <slaweq> amotoki: yamamoto ralonsoh any thoughts? are You ok to approve rfe? 14:52:13 <ralonsoh> ok to approve but I have concerns about it 14:52:24 <ralonsoh> so we can discuss it in the spec 14:52:45 <amotoki> I am okay to approve it (while I still don't know the real usecase but yamamoto says he has similar experiences) 14:53:01 <slaweq> amotoki: yes, that is what convinced me too :) 14:53:02 <yamamoto> range thing is fine. N-1 thing is concerning. 14:53:40 <amotoki> I know the port forwarding API is mainly designed for listen ports, but if we add a forwarding rule for a higher port number theoretically it is possible for an internal side to start a connection with the port and we need to check what happens before allowing N-1 thing. 14:54:21 <amotoki> (it can be discussed in the spec of course) 14:54:42 <slaweq> ok, so lets approve rfe as on idea of extending PF API to allow ranges 14:54:49 <slaweq> and lets discuss N-1 mapping in the spec 14:55:03 <slaweq> if that don't make sense we may only go with N-N mapping finally 14:55:30 <yamamoto> +1 14:55:33 <amotoki> sounds fine 14:55:53 <ralonsoh> ok 14:55:57 <slaweq> ok, thx 14:56:05 <slaweq> so I will mark rfe as approved 14:56:16 <slaweq> thx rafaelweingartne for proposing it and work working on that 14:56:28 <slaweq> and that's all what I had for You today 14:56:29 <yamamoto> amotoki: my usecase was with some weird application. i think it was a game. but i don't remember details. it's long ago. 14:56:41 <amotoki> yamamoto: hehe 14:57:02 <slaweq> thx for attending the meeting 14:57:07 <slaweq> and have a great weekend 14:57:09 <slaweq> o/ 14:57:11 <rafaelweingartne> ok, thanks guys 14:57:12 <ralonsoh> bye 14:57:13 <slaweq> #endmeeting