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