| opendevreview | Miguel Lavalle proposed openstack/neutron master: Router flavors and service type for OVN https://review.opendev.org/c/openstack/neutron/+/883988 | 01:55 |
|---|---|---|
| ykarel | slaweq, ack | 05:55 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Reproduce issue https://review.opendev.org/c/openstack/neutron/+/900574 | 06:20 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004 | 07:45 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-bgp-agent master: Add support at NB BGP Driver for exposing OVN LBs https://review.opendev.org/c/openstack/ovn-bgp-agent/+/899120 | 09:21 |
| opendevreview | Takashi Kajinami proposed openstack/os-ken master: Avoid RuntimeError caused by iteration over sys.modules https://review.opendev.org/c/openstack/os-ken/+/900601 | 09:29 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-bgp-agent master: Add support at NB BGP Driver for exposing tenant IPs https://review.opendev.org/c/openstack/ovn-bgp-agent/+/899117 | 09:55 |
| opendevreview | Lucas Alvares Gomes proposed openstack/neutron master: [OVN] Update the External Ports documentation https://review.opendev.org/c/openstack/neutron/+/900030 | 10:15 |
| opendevreview | Jayce Houtman proposed openstack/neutron master: Change exception messages to error log messages for DNS integration. https://review.opendev.org/c/openstack/neutron/+/900212 | 13:13 |
| mlavalle | haleyb: are we meeting today? | 13:59 |
| haleyb | mlavalle: yes, sorry hadn't sent agenda | 13:59 |
| haleyb | hopefully we are quick, it's a holiday for me :) | 14:00 |
| haleyb | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Nov 10 14:00:30 2023 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| slaweq | o/ | 14:00 |
| obondarev_ | o/ | 14:00 |
| mlavalle | o/ | 14:00 |
| *** obondarev_ is now known as obondarev | 14:01 | |
| mlavalle | haleyb: veterans day? | 14:01 |
| haleyb | mlavalle: yes, and i didn't even know until yesterday | 14:01 |
| mlavalle | it's in our calendar, but it is not a holiday for us | 14:02 |
| lajoskatona | o/ | 14:02 |
| haleyb | jlibosva, racosta_: are you around? you have the agenda items today | 14:02 |
| jlibosva | o/ | 14:02 |
| jlibosva | I am | 14:03 |
| racosta_ | o/ | 14:03 |
| jlibosva | shall I start? | 14:03 |
| haleyb | ok, i think we have quorom | 14:03 |
| racosta_ | please, go ahead jlibosva. | 14:03 |
| jlibosva | I'm not familiar with the format of this meeting so I guess once we enter the "on demand agenda" I shall start? | 14:04 |
| mlavalle | yeah go ahead | 14:05 |
| mlavalle | we can improvise a bit | 14:05 |
| haleyb | jlibosva: right, we can go right to on-demand | 14:05 |
| haleyb | #topic on-demand | 14:06 |
| haleyb | :) | 14:06 |
| jlibosva | ok, thanks :) so I was told to bring this topic here, it's related to ports and its bindings | 14:07 |
| jlibosva | #link https://review.opendev.org/c/openstack/neutron/+/892815 | 14:07 |
| jlibosva | so we can have multiple mech drivers configured and based on the vif type the driver binds the port on a host | 14:07 |
| jlibosva | the vif type allows PUT actions (Updated) in the API layer so it's currently possible to change the type while a port is bound | 14:08 |
| obondarev | but that will not be a correct change, right? | 14:09 |
| jlibosva | now since API is uses stateless resources - ie we don't know if the updated port is bound or not until we look at the DB, which is layer below API, we can't forbid the update operation on port. So I made the patch to fail changing type if port is bound on the db layer | 14:09 |
| jlibosva | obondarev: right | 14:09 |
| jlibosva | there was a bug in Nova too that if user changed the type, the networking went down. From the Nova perspective this should not be an allowed operation too. And I agree | 14:10 |
| obondarev | so it's not an API change to me, just handling an incorrect request | 14:10 |
| jlibosva | or - if the type is changed we would need to re-bind the port | 14:10 |
| jlibosva | yes, I agree with obondarev. the state a port is in should not allow the change | 14:11 |
| jlibosva | there are some concerns on the review that would be good to discuss here | 14:11 |
| jlibosva | Rodolfo and Lajos had some concerns and I see Lajos just dropped and Rodolfo is on PTO | 14:12 |
| obondarev | so what happens currently when someone updates vif_type of a bound port? | 14:14 |
| haleyb | this is vnic_type right? | 14:14 |
| slaweq | why do we want to allow changing that on unbound ports? Maybe it would be better (and easier) to simply forbid that on the API level for all types of ports, wdyt? | 14:15 |
| jlibosva | yes, the attribute is vnic_type, sorry | 14:15 |
| jlibosva | slaweq: the only scenario I could think of would be that someone wants to create a port (like SR-IOV) and forgets to set the type. so instead of deleting the resource and re-creating one can just update, if it's not bound | 14:16 |
| obondarev | just like any other update I think | 14:16 |
| slaweq | but in such case user can easily delete and then create port again | 14:16 |
| obondarev | not save 1 API call at least :) | 14:16 |
| obondarev | to* | 14:16 |
| jlibosva | as for what happens, I think there will be inconsistency when mechanism drivers or agents query that attribute | 14:17 |
| lajoskatona | sorry seems I have some network issue | 14:18 |
| haleyb | are there any other questions? | 14:23 |
| mlavalle | so let me attempt to summarize the issue: over the years, we, the Neutron community, allowed a certain specific case of a port update and now we realize we shouldn't have | 14:23 |
| jlibosva | so I guess there are two ways how to approach it? 1) disallow to update the attribute on API level 2) always check if the port is bound if the attribute is updated on the DB level (the linked patch) | 14:23 |
| lajoskatona1 | I think I have now working network, sorry for popping up and down | 14:24 |
| obondarev | can 2 also include api-ref note? | 14:24 |
| haleyb | and if 2) does it need to be discoverable with an extension | 14:24 |
| lajoskatona1 | yes my concern was to add an extension to show the users that hey the api behaves deifferently | 14:24 |
| mlavalle | so we want to fix the bahavior but we worry about changing the behavior. Let's make that behavior discoverable and maybe optional | 14:24 |
| lajoskatona1 | Iyes good summary | 14:25 |
| obondarev | but could anyone used it for any good reason? | 14:25 |
| lajoskatona1 | I am not sure to be that rigid and even for bug fix add extension | 14:25 |
| lajoskatona1 | perhaps not necessary and better to fix it | 14:25 |
| mlavalle | obondarev: it doesn't seem logical, but we just don't know | 14:25 |
| slaweq | I'm not sure we need extension for that - we will just prevent users from doing something what can lead only to the bad things finally so IMO release note would be enough in this case | 14:26 |
| lajoskatona1 | so my goal was to discuss it and have consensus before just doing anything unchangble | 14:26 |
| obondarev | agree with slaweq | 14:26 |
| mlavalle | I would be ok with just fixing it. I was not advicating a position, just weighing the alternatives | 14:27 |
| lajoskatona1 | as I remember from ralonsoh's comment he had the concern | 14:27 |
| jlibosva | #link https://bugs.launchpad.net/nova/+bug/1981813 | 14:27 |
| jlibosva | there is the nova portion and how it was discovered | 14:27 |
| haleyb | right, if the change results in an unusable resource i would think an error is appropriate | 14:27 |
| haleyb | in my opinion | 14:28 |
| obondarev | + | 14:28 |
| lajoskatona1 | +1 | 14:28 |
| mlavalle | +1 | 14:29 |
| haleyb | i was going to ask for a vote, but there it is | 14:29 |
| lajoskatona1 | and if there is no API extension we can backport it | 14:29 |
| lajoskatona1 | as I see from the nova bug the fix was backported | 14:29 |
| mlavalle | teah, that's a plus | 14:30 |
| mlavalle | yeah | 14:30 |
| haleyb | so we proceed as a bug fix and don't require an extension | 14:31 |
| haleyb | slaweq: opinion? | 14:31 |
| slaweq | I'm good with that, no extension needed IMO | 14:31 |
| haleyb | ok, i'll take the +1's as consensus on moving forward without an extension | 14:32 |
| slaweq | regarding backport - I think we should maybe ask stable core team for opinion also | 14:32 |
| slaweq | but personally I don't see reason why we shouldn't backport it | 14:32 |
| haleyb | good discussion on the topic | 14:32 |
| jlibosva | thanks everyone | 14:32 |
| mlavalle | jlibosva: thanks for bringing it up :-) | 14:32 |
| jlibosva | the credit goes to lajoskatona1 :) | 14:33 |
| lajoskatona1 | I stopped the thing, sorry for that | 14:33 |
| mlavalle | yeah, but you also took the time to chat with us today | 14:33 |
| jlibosva | that's always a pleasure | 14:33 |
| haleyb | slaweq: it seems like the nova-related change was backported, so i would +1 a backport | 14:33 |
| haleyb | of course that was a CVE | 14:34 |
| slaweq | good for me then | 14:34 |
| mlavalle | yeah, otherwise the whole thing is useless | 14:34 |
| lajoskatona1 | +1 for backport with re-no | 14:34 |
| jlibosva | well, afaiu Nova doesn't need the Neutron patch. They basically just made Nova aware that the type can be changed in Neutron. Which they didn't count with before | 14:35 |
| jlibosva | just to make it clear :) | 14:35 |
| haleyb | jlibosva: so just to confirm - change is good, but add rlease note, and you will update the api-ref? | 14:35 |
| jlibosva | haleyb: yesir | 14:35 |
| haleyb | ack, thanks | 14:36 |
| haleyb | racosta_: ok, we can move on to your items | 14:36 |
| racosta_ | ok, thanks. | 14:36 |
| racosta_ | Although I added the same topics I presented at PTG, I believe that's required a formal ack for RFE's in driver meetings. | 14:36 |
| racosta_ | # RFE: BGP peer connect mode. I think we're on track in this one. | 14:37 |
| racosta_ | #link https://review.opendev.org/c/openstack/neutron-specs/+/899210 | 14:37 |
| racosta_ | It is basically a new configurable parameter to keep the connection with the BGP peer 'active' and avoid unnecessary disconnections if it enters an idle state on the switch side. | 14:37 |
| haleyb | #link https://bugs.launchpad.net/neutron/+bug/2006145 | 14:37 |
| racosta_ | It's a trivial change on the n-d-r side, and will be configurable to allow compatibility with anyone who uses the default passive default. | 14:39 |
| racosta_ | *passive mode | 14:40 |
| racosta_ | Any questions or comments on this? | 14:40 |
| lajoskatona1 | nothing from me | 14:41 |
| haleyb | not from me, thinks it fixes a valid issue | 14:42 |
| mlavalle | +1 | 14:42 |
| haleyb | +1 | 14:42 |
| obondarev | no questions | 14:42 |
| obondarev | +1 | 14:42 |
| slaweq | IIRC obondarev had some concerns in the spec review, right? | 14:42 |
| obondarev | ah, did I? Let me check | 14:43 |
| slaweq | no, I think I messed it with some other spec, sorry :) | 14:43 |
| obondarev | ok, no worries :) | 14:43 |
| haleyb | slaweq, lajoskatona1: votes? to make it official | 14:44 |
| slaweq | +1 | 14:44 |
| lajoskatona1 | +1 | 14:44 |
| haleyb | ok, thanks, i've marked it rfe-approved | 14:45 |
| racosta_ | ok, thanks. we can move on to the next | 14:45 |
| racosta_ | #RFE: BGP speaker peer sessions resilient. This one is related to RMQ/Infra failures. | 14:45 |
| racosta_ | # LP: https://bugs.launchpad.net/neutron/+bug/2006145 | 14:46 |
| racosta_ | #link https://review.opendev.org/c/openstack/neutron-specs/+/899209 | 14:46 |
| racosta_ | It's a little more complex. The goal is to introduce a new speaker cache logic for the DRAgent can keep the speaker settings and the BGP peer sessions in case of RPC Exceptions, and/or reestablishment of communication via RPC. Basically: a new config option 'speaker_cache_timeout'. | 14:46 |
| racosta_ | In the RFE proposal, the cache timeout time is configurable and can be adjusted according to the time it actually takes for the RMQ to respond correctly again (transient time after RMQ/Infra comes back - cluster convergence, mysql issues, etc.) | 14:47 |
| racosta_ | There would be another way to do it, as Felix's suggestion. | 14:47 |
| racosta_ | It could be implemented as long as we noticed when the RMQ was offline and online, but I didn't find how to obtain this information via oslo_messaging (it would only be possible to experience timeouts in this case). | 14:48 |
| racosta_ | I think the cache timeout solves transient RMQ issues. | 14:49 |
| racosta_ | Any questions or comments on this? | 14:49 |
| haleyb | i think mine were answered in the bug | 14:51 |
| racosta_ | yeah | 14:51 |
| lajoskatona1 | If i understand well in case of such rmq issue the agent removed the bgp settings? | 14:53 |
| obondarev | I'm a bit confused, https://bugs.launchpad.net/neutron/+bug/2006145 does not sound like an RFE, but rather like a bug description | 14:54 |
| racosta_ | yesh, it can remove the complete BGP speaker confg if the RPC return is empty value | 14:54 |
| obondarev | and it was already marked as approved | 14:54 |
| lajoskatona1 | I like the idea to keep these settings till the agent can connect again (if it is below the timeout) | 14:55 |
| lajoskatona1 | so +1 from me to the proposal | 14:55 |
| mlavalle | +1 from me as well | 14:56 |
| haleyb | obondarev: i maybe should have marked it rfe-triaged | 14:57 |
| racosta_ | this was an old thread in the original bug obondarev, issue or RFE? IMO this is a BUG, but as there was no consensus I proposed as RFE... | 14:57 |
| haleyb | and since adding the config option was necessary i believe was the reason | 14:58 |
| obondarev | I see, so there are 2 specs for a single RFE https://bugs.launchpad.net/neutron/+bug/2006145? | 14:58 |
| obondarev | https://review.opendev.org/c/openstack/neutron-specs/+/899209 and https://review.opendev.org/c/openstack/neutron-specs/+/899210 | 14:59 |
| racosta_ | no no, are different cases. | 14:59 |
| obondarev | ah, sorry, my bad | 15:00 |
| racosta_ | no worries, but the two are related to the n-d-r (BGP sessions). | 15:00 |
| obondarev | I just had 2 same tabs opened :) | 15:01 |
| obondarev | I'm ok with this RFE and spec, +1 | 15:02 |
| haleyb | +1 from me too | 15:02 |
| slaweq | +1 from me too | 15:02 |
| lajoskatona1 | +1 | 15:02 |
| haleyb | ok, thanks | 15:02 |
| mlavalle | +1 | 15:02 |
| haleyb | and since that was all on the agenda, and we're over time, we are done | 15:03 |
| slaweq | o/ | 15:03 |
| haleyb | thanks everyone for attending, have a good weekend | 15:03 |
| haleyb | #endmeeting | 15:03 |
| opendevmeet | Meeting ended Fri Nov 10 15:03:38 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:03 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-11-10-14.00.html | 15:03 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-11-10-14.00.txt | 15:03 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-11-10-14.00.log.html | 15:03 |
| lajoskatona1 | o/ | 15:03 |
| lajoskatona1 | bye | 15:03 |
| mlavalle | o/ | 15:03 |
| racosta_ | thanks folks, have a nice weekend! enjoy your holiday haleyb! | 15:03 |
| * haleyb is out today but feel free to approve any of my changes that fix bugz | 15:04 | |
| obondarev | o/ | 15:04 |
| seba | I still have a problem with a core_plugin.get_port() breaking my transaction. how does transaction concurrency work? what happens if someone creates a new db session in an already running transaction? | 15:26 |
| seba | explicitly it looks like the TrunkPlugin has a resource_extend that creates its own db session | 15:27 |
| seba | https://opendev.org/openstack/neutron/src/commit/26f173423986ca6c110ee517bae8d5db844d6ad6/neutron/services/trunk/plugin.py#L84-L85 | 15:27 |
| seba | I have not found any other resource_extend that extends a port that needs a db session that creates its own context. in most cases they seem to be using the db object's session? | 15:28 |
| seba | (if they need one at all) | 15:28 |
| ykarel | slaweq, when you get chance pleace check https://review.opendev.org/c/openstack/neutron/+/900466 | 15:35 |
| slaweq | ykarel approved | 15:37 |
| ykarel | thx | 15:45 |
| slaweq | ykarel please approve https://review.opendev.org/c/openstack/neutron/+/900406 then :) | 15:45 |
| ykarel | slaweq, done, i had a qestion there regarding backport to stable/2023.2 | 15:50 |
| slaweq | ykarel yes, I was going to propose backport once this patch will be merged in u/s | 15:50 |
| ykarel | ack thx | 15:51 |
| slaweq | it's just tests change so there's no any reason not to backport it | 15:51 |
| ykarel | +1 | 15:51 |
| *** ykarel is now known as ykarel|away | 15:51 | |
| spatel | Folks, I have very odd requirement. If I have my all compute nodes dedicatedly assigned for sriov workload in that case do I still need neutron-openvswitch-agent running on all compute nodes? I only need neutron-sriov-agent on compute nodes which by pass PCI to vm. | 16:01 |
| spatel | Are there any issue if not deploy neutron-openvswitch-agent on sriov compute nodes? | 16:02 |
| opendevreview | Merged openstack/neutron master: Revert "Make job openstack-tox-py310-with-sqlalchemy-master non-voting temporary" https://review.opendev.org/c/openstack/neutron/+/900466 | 16:02 |
| * SvenKieske is wondering this as well (never deployed sriov only nodes before) | 16:05 | |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004 | 16:21 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004 | 16:23 |
| opendevreview | Lajos Katona proposed openstack/tap-as-a-service master: Add pyproject.toml to support pip 23.1 https://review.opendev.org/c/openstack/tap-as-a-service/+/900639 | 17:13 |
| opendevreview | Merged openstack/neutron master: [Fullstack] Drop all linuxbridge scenarios from fullstack tests https://review.opendev.org/c/openstack/neutron/+/900406 | 17:56 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/886004 | 18:35 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!