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