14:00:23 <lajoskatona> #startmeeting neutron_drivers
14:00:23 <opendevmeet> Meeting started Fri May 27 14:00:23 2022 UTC and is due to finish in 60 minutes.  The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:25 <opendevreview> Slawek Kaplonski proposed openstack/neutron master: Use new combined neutron_tempest_plugin as nftables jobs parent  https://review.opendev.org/c/openstack/neutron/+/843618
14:00:25 <lajoskatona> o/
14:00:25 <mlavalle2> o/
14:00:25 <opendevreview> Slawek Kaplonski proposed openstack/neutron master: Update ci jobs docs  https://review.opendev.org/c/openstack/neutron/+/843619
14:00:46 <amotoki> hi
14:00:48 <mtomaska> o/
14:01:16 <slaweq> o/
14:02:11 <lajoskatona> I think we can start
14:02:18 <lajoskatona> We have one RFE for today:
14:02:25 <lajoskatona> [RFE] Allow setting --dst-port for all port based protocols at once (#link https://bugs.launchpad.net/neutron/+bug/1973487)
14:03:11 <lajoskatona> the idea seems valid for me
14:03:27 <mtomaska> Background: This came from a customer I have been working with
14:04:06 <lajoskatona> mtomaska: yeah that is mentioned in one of the comments
14:04:07 <slaweq> AFAIK current behaviour is consistent with e.g. iptables
14:04:50 <mtomaska> my main concern is if that option can bring some implications. In another words...
14:04:53 <slaweq> and if we will accept protocol "any" and some port, we will need to apply many rules in e.g. iptables (I'm not sure about ovn and ovs fw)
14:05:19 <amotoki> dst-port is L4 field so it totally depends on L4 protocol. How can we support all L4 protocol?
14:06:23 <amotoki> I am not sure how we can determine if a L4 protocol is port-based.
14:06:46 <ralonsoh> (hi, sorry, network problems)
14:08:40 <mtomaska> Do you see any corner cases such that specifying '--protocol all_l4' would case problems on some systems? The 'all_l4' protocol arg will just iterate over this list of protocols
14:08:45 <mtomaska> https://github.com/openstack/neutron/blob/master/neutron/common/_constants.py#L23-L29
14:10:03 <mlavalle2> and maybe we should not get so hung up on the "L4" piece. If we were going to implement this, we would clarify the list of protocols supported by the feature
14:10:08 <mtomaska> I also want to mention that customer was just annoyed that they have to issue cli command for each --protocol (udp | tcp and so on). The counter argument could be that its not hard to automate it :)
14:11:03 <lajoskatona> mlavalle2: aggree the bases of that should be the above constant
14:11:12 <mlavalle2> yeap
14:11:19 <amotoki> mlavalle2: +1
14:11:42 <slaweq> there is 5 protocols in that list mtomaska so is it really that hard for the customer to automate it on the client's side?
14:12:06 <obondarev> hi, sorry for being late
14:12:09 <slaweq> IMHO it sounds like something what should be done on the client's side really
14:12:10 <mtomaska> slaweq. IDK but that was my response as well :)
14:12:23 <lajoskatona> Is there any difference if the user call 5 CLIs to issue this or doing the same with one call from iptables or such perspective?
14:12:37 <opendevreview> yatin proposed openstack/neutron master: [WIP] Switch fullstack/functional fips jobs to 9-stream  https://review.opendev.org/c/openstack/neutron/+/843245
14:12:50 <slaweq> otherwise You will then have SG rule with protocol "all_l4" (all whatever else) and will need to use in docs what that exactly means
14:13:02 <lajoskatona> the client side was in my mind also, not sure if HEAT can do such thing for example
14:13:39 <slaweq> I'm not going to block this rfe, but personally I'm not very enthusiastic about it :)
14:13:42 <mlavalle2> ah,, so implement this somewhere in OpenStack, although not necessarily thorugh the Neutron API
14:14:13 <haleyb> as a data point it doesn't look like iptables allows this behavior, you have to make individual rules using -p individually
14:14:39 <mtomaska> apparently heat only supports tcp. udp and icmp https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Neutron::SecurityGroup
14:15:18 <mlavalle2> but I think that what was meant is that this might be a RFE for Heat, or the clients
14:15:30 <mlavalle2> regardless of what they support right now
14:15:40 <lajoskatona> mtomaska: so there's thing to do in heat also
14:15:45 <opendevreview> Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Update OVS and OVN branches used in the CI jobs  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/843622
14:17:19 <lajoskatona> ok, so if iptables anyway works this way let's say it is better to do it from the client side
14:17:31 <mtomaska> right, we could propose that HEAT supports other two protocols from the list. That is UDP-Lite dccp and sctp
14:17:38 <amotoki> I personally am not very excited with this proposal. this looks like an area where some automation tool (or client side) can cover (as others already mentioned)
14:18:24 <mtomaska> this way the user has few option to automate. Write your own script :), use HEAT, use Ansible
14:18:50 <mtomaska> or whatever they like to use to automate
14:19:16 <mlavalle2> or even without automation on the part of the operator, if this were to be implemented in the openstack client
14:19:45 <opendevreview> Edward Hope-Morley proposed openstack/neutron stable/xena: Partially revert "Do not link up HA router gateway in backup node"  https://review.opendev.org/c/openstack/neutron/+/843582
14:19:49 <mlavalle2> the client might be the right place in the stack to implement this
14:19:54 <slaweq> mtomaska exactly, and plus value of such solution is that when he will do SG rules list, he will see all rules which are really created by backend
14:20:27 <lajoskatona> mlavalle2: you mean openstacksdk?
14:20:49 <mlavalle2> maybe
14:21:21 <mtomaska> ok so who votes for "automate at the client side" ?
14:21:23 <mtomaska> o/
14:21:24 <mlavalle2> I think through this discussion we have higlighted that it is not clear where in the stack is the best place to implement this
14:21:25 <amotoki> potentially OSC can accept a list of protocols as --protocol argument. if so, the next question is how osc should behave if a subset of protocols fails (e.g. as dst-port is not supported)
14:21:32 <lajoskatona> slaweq, mtomaska: that is also good point that the list will be clear, and will display all protocol-port pair
14:22:48 <mlavalle2> but it seems the Neutron API is unlikely to be that place
14:23:20 <lajoskatona> mtomaska: after this discussion I vote to place it to the client side
14:23:21 <haleyb> amotoki: that's a good question, which is maybe why i don't like this proposal
14:23:39 <amotoki> haleyb: yeah
14:23:47 <opendevreview> Slawek Kaplonski proposed openstack/neutron-lib master: Check proper config option to see if scope is enforced or not  https://review.opendev.org/c/openstack/neutron-lib/+/839956
14:24:36 <haleyb> i am curious about the API impact - on a POST today you get back a single object, is returning many even an option?
14:25:41 <ralonsoh> I think amotoki could be a good alternative, IMO
14:25:52 <ralonsoh> amotoki's idea
14:26:33 <amotoki> haleyb: the neutron API supports bulk creation of resources. I think if we would like to create multiple sg rules, bulk creation would be used.
14:26:56 <mlavalle2> yeap
14:26:58 <haleyb> amotoki: thanks for reminding me of that
14:27:52 <lajoskatona> but no bulk for security-groups or rules
14:28:09 <ralonsoh> not yet, no
14:28:38 <amotoki> ah, I haven't checked which resources support bulk creation
14:29:05 <mlavalle2> yes, but it means that the concept of bulk creation in general is compatible with the API
14:29:26 <mlavalle2> it wouldn't be an aberration
14:29:38 <lajoskatona> malavalle2: +1
14:29:48 <amotoki> mlavalle2: +1
14:32:14 <lajoskatona> so generally we agree that it is better to be done on the client side, but perhaps Neutron need bulk support for security-groups and rules, am I right?
14:32:37 <amotoki> lajoskatona: it sounds good
14:32:51 <amotoki> IIRC, another point on bulk creation is osc and sdk have no support for bulk creation right now
14:32:54 <mtomaska> sounds good to me
14:33:14 <lajoskatona> amotoki: thanks
14:33:14 <slaweq> +1
14:33:15 <ralonsoh> I think so if we want to, for example, fail and remove any SG already created
14:33:26 <mlavalle2> yes, but I don't think we have a pressing need for SG bulk creation
14:33:37 <mlavalle2> with that clarification +1
14:34:04 <lajoskatona> thanks
14:34:21 <lajoskatona> summary the RFE is not accepted
14:35:45 <lajoskatona> ok, if no more comments on this we can move on
14:36:31 <lajoskatona> #topic On Demand Agenda
14:36:39 <lajoskatona> (lajoskatona): meaning of option "router_auto_schedule" is ambiguous (#link https://bugs.launchpad.net/neutron/+bug/1973656 )
14:39:32 <lajoskatona> if I understand well the original question was to rename router_auto_schedule to something else
14:40:06 <lajoskatona> and an intersting discussion is now under this question, with haleyb and obondarev with their good memories :-)
14:40:39 <ralonsoh> according to the LP comments, I think we should improve the documentation
14:40:49 <ralonsoh> but I'm not sure about the name change
14:41:05 <obondarev> +1 for doc improve
14:41:10 <slaweq> I'm looking now at network_auto_schedule option, which is pretty similar but for the networks to be scheduled to the dhcp agents
14:41:17 <slaweq> and it seems from https://github.com/openstack/neutron/blob/aff0a75ecb76e12f240b4ab00a8ecfc75776216b/neutron/db/agentschedulers_db.py#L481
14:41:21 <ralonsoh> ^^ exactly
14:41:59 <lajoskatona> good analogy
14:42:16 <slaweq> that it would control if neutron should try to schedule networks automatically to the dhcp agents or not
14:42:44 <slaweq> and that works in case when networks are removed from dead agents
14:42:48 <slaweq> and also e.g. for new networks
14:42:54 <slaweq> at least that's how it looks like for me
14:42:56 <amotoki> router_auto_schedule is also used for initial scheduling just after a router is created, right?
14:43:03 <amotoki> https://github.com/openstack/neutron/blob/aff0a75ecb76e12f240b4ab00a8ecfc75776216b/neutron/api/rpc/handlers/l3_rpc.py#L109
14:43:15 <mlavalle2> that's my understanding
14:44:01 <lajoskatona> I agree to improve the documentation
14:44:33 <mlavalle2> seems like a good next step
14:45:35 <mlavalle2> we really don't know how this is being used in the wild, but since we don't have many complaints, it is not probably wise to mess with it
14:45:59 <mlavalle2> so let's improve documentation
14:45:59 <lajoskatona> ok, then I add to the bug as comment that the cfg option name is good, but the doc can be improved
14:46:04 <slaweq> IMO this is valid bug
14:46:16 <slaweq> and we should check if that option is enabled e.g. in https://github.com/openstack/neutron/blob/430abde13ec58e611a8752ca579fee5110a0a61d/neutron/db/l3_agentschedulers_db.py#L484
14:46:44 <slaweq> so it would probably work the same way like network_auto_schedule option for dhcp agents
14:48:23 <lajoskatona> as I see the first step anyway is to document to have it written how it behaves currently and act if there are complaints for that
14:49:14 <amotoki> the router scheduler class have both auto_schedule_routers() and schedule(). I am not sure schedule() should work only when auto_schedule is enabled
14:49:14 <ralonsoh> +1
14:49:16 <mlavalle2> yeah, let's make it clear to everybody in doc how it is intended to bahave
14:49:17 <slaweq> lajoskatona I agree, we should check it to be sure, document how it works and then maybe change this behaviour a bit if that will be needed
14:49:20 <amotoki> anyway agree to imporve the doc
14:49:44 <ralonsoh> and yes, we should check amotoki's question
14:51:03 <lajoskatona> ok, let's go this way then, improve the doc first
14:51:09 <mlavalle2> +1
14:51:28 <amotoki> +1
14:51:31 <ralonsoh> +1
14:51:35 <slaweq> +1
14:51:48 <haleyb> +1
14:51:49 <lajoskatona> +1
14:52:15 <obondarev> +1
14:52:45 <lajoskatona> ok, thank you very much
14:52:55 <lajoskatona> Is there anything to discuss?
14:53:07 <slaweq> nothing from me
14:53:28 <amotoki> none from me
14:53:47 <mlavalle2> not from me
14:53:56 <lajoskatona> #endmeeting