Tuesday, 2023-07-04

opendevreviewMiguel Lavalle proposed openstack/neutron master: [PoC][DNM] Router flavors and service type for OVN  https://review.opendev.org/c/openstack/neutron/+/88398800:16
sondx25ralonsoh, I set the QoS tap interface of the VM to qdisc fq_codel, but the network performance is still not improved. Please help me.03:17
ykarelContinuity, what ovn version you using?05:32
ykarelthere were some fixes for fip + vlan in core ovn like https://bugzilla.redhat.com/show_bug.cgi?id=2007120 + multiple fixes in neutron like https://bugs.launchpad.net/neutron/+bug/200345505:34
ykarelmay be you missing some of those?05:34
opendevreviewLuis Tomas Bolivar proposed openstack/ovn-bgp-agent master: Make debug log less chatty  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/88755005:57
opendevreviewZhouHeng proposed openstack/neutron master: Set result when lswitch port exist  https://review.opendev.org/c/openstack/neutron/+/88177106:15
Continuityykarel: thanks ill take a look and see where we are in regards to those 06:31
sondx25ykarel, - I use OpenStack + ML2/OVN (OpenStack Yoga, OVN 22.03.0, Open vSwitch 2.17.0).06:51
sondx25- Initially, the Compute node has only a few virtual machines, I see bandwidth between 2 VMs (in the same self-service network) in the same Compute node is 20 Gbps. Then the number of virtual machines at the Compute node increased to 100 VMs, (but the CPU used of node Compute only 30%), then I see bandwidth between 2 VMs (in the same self-service network) in this Compute node is 6 Gbps.06:51
sondx25- Note: This does not happen with OpenStack Yoga, ML2/OpenvSwitch configuration:06:51
sondx25[securitygroup]06:51
sondx25firewall_driver = iptables_hybrid06:51
sondx25ykarel, In case, my system uses OpenStack + ML2/OVN (OpenStack Yoga, OVN 22.03.0, Open vSwitch 2.17.0).06:55
sondx25The number of virtual machines at the Compute node increased to 100 VMs, (but the CPU used of node Compute only 30%), then I see bandwidth between 2 VMs (in the same self-service network) in this Compute node is 6 Gbps.06:55
sondx25At this point, I disable port security and security group all ports of that self-service network, then the bandwidth between 2 VMs reaches 20 Gbps again.06:55
sondx25ralonsoh, - I use OpenStack + ML2/OVN (OpenStack Yoga, OVN 22.03.0, Open vSwitch 2.17.0).06:58
sondx25- Initially, the Compute node has only a few virtual machines, I see bandwidth between 2 VMs (in the same self-service network) in the same Compute node is 20 Gbps. Then the number of virtual machines at the Compute node increased to 100 VMs, (but the CPU used of node Compute only 30%), then I see bandwidth between 2 VMs (in the same self-service network) in this Compute node is 6 Gbps.06:58
sondx25At this point, I disable port security and security group all ports of that self-service network, then the bandwidth between 2 VMs reaches 20 Gbps again.06:58
sondx25- Note: This does not happen with OpenStack Yoga, ML2/OpenvSwitch configuration:06:58
sondx25[securitygroup]06:58
sondx25firewall_driver = iptables_hybrid06:58
sondx25- Please see detail in video (https://youtu.be/Xnsyo0DZZO8).06:58
ralonsohsondx25, we talked yesterday about this. You can ask this question in the OVN mailing list. If this problem is due to the conntrack table, this could be treated as an improvement in core OVN07:17
ralonsohyou can also use DPDK in your environment07:17
ralonsohand if the performance is that important, you can also use HW offload (that requires an additional cost)07:18
ralonsohsondx25, do you have the same test video with ML2/OVS and hybrid firewall? 07:21
opendevreviewZhouHeng proposed openstack/neutron master: Set result when lswitch port exist  https://review.opendev.org/c/openstack/neutron/+/88177107:25
ykarelsondx25, yeap would be better to ask ovn mail list as Rodolfo suggested. I am unsure what causing this, but increasing vm and performance drop is a good data point07:37
opendevreviewRodolfo Alonso proposed openstack/neutron master: Add a new extension "security-groups-rules-belongs-to-default-sg"  https://review.opendev.org/c/openstack/neutron/+/88390707:49
opendevreviewMerged openstack/ovn-bgp-agent master: Make debug log less chatty  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/88755008:13
ykarelralonsoh, sondx25 to rule out conntrack involvement may be can try stateless security group?08:14
ralonsohykarel, sondx25 or use remote CIDR instead of remote group (that affects the OF rules, not directly the conntrack rules). But worth to try both options08:15
ykarel+108:15
opendevreviewZhouHeng proposed openstack/neutron master: Improve ACL comparison efficiency  https://review.opendev.org/c/openstack/neutron/+/88544908:19
sondx25rolonsoh, I used remote CIDR and remote group, the results are the same.08:29
sondx25ykarel, rolonsoh, I try to use stateless security group, great bandwidth result is 20 Gbps.08:40
opendevreviewLucas Alvares Gomes proposed openstack/neutron stable/2023.1: [OVN] Expose chassis hosting information in LSP  https://review.opendev.org/c/openstack/neutron/+/88757908:41
ralonsohsondx25, so as you presumed yesterday, this is an "issue" in the conntrack module08:41
opendevreviewLucas Alvares Gomes proposed openstack/neutron stable/zed: [OVN] Expose chassis hosting information in LSP  https://review.opendev.org/c/openstack/neutron/+/88758008:41
opendevreviewLucas Alvares Gomes proposed openstack/neutron stable/yoga: [OVN] Expose chassis hosting information in LSP  https://review.opendev.org/c/openstack/neutron/+/88758108:41
opendevreviewLucas Alvares Gomes proposed openstack/neutron stable/xena: [OVN] Expose chassis hosting information in LSP  https://review.opendev.org/c/openstack/neutron/+/88758208:42
opendevreviewLucas Alvares Gomes proposed openstack/neutron stable/wallaby: [OVN] Expose chassis hosting information in LSP  https://review.opendev.org/c/openstack/neutron/+/88758308:42
ykarelsondx25, ralonsoh great, found https://developers.redhat.com/articles/2022/11/17/benchmarking-improved-conntrack-performance-ovs-300#performance_statistics significant improvement in ovs>=3.0.0 wrt this08:45
sondx25ykarel, rolonsoh, Thank you so much for your help.09:04
ykarelThanks sondx25 for checking, would be good if you also update the launchpad bug with all these findings https://bugs.launchpad.net/neutron/+bug/199659309:26
sondx25ykarel, This bug (https://bugs.launchpad.net/neutron/+bug/1996593) was posted by myself. I will update it.09:33
ykarelyeap i noticed that :)09:33
opendevreviewRodolfo Alonso proposed openstack/neutron master: [FT] Move ``BaseOVSTestCase`` class to concurrency 1 executor  https://review.opendev.org/c/openstack/neutron/+/88759009:51
sondx25ykarel, i see, thank you :)10:02
opendevreviewSlawek Kaplonski proposed openstack/neutron-tempest-plugin master: Add "-d 1" option to the ncat client.  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/88759110:15
Continuityykarel: we are running OVN22.10, we are using kolla ansible to deploy10:35
opendevreviewRodolfo Alonso proposed openstack/neutron master: Use the new network HA parameter  https://review.opendev.org/c/openstack/neutron/+/88174210:58
sondx25ykarel, https://developers.redhat.com/articles/2022/11/17/benchmarking-improved-conntrack-performance-ovs-300#  .  This article is about conntrack in userspace datapath.  I am using kernel.11:00
opendevreviewBence Romsics proposed openstack/neutron master: ovs-agent: React to DB down just like to server down  https://review.opendev.org/c/openstack/neutron/+/88725711:02
opendevreviewZhouHeng proposed openstack/neutron master: Set result when lswitch port exist  https://review.opendev.org/c/openstack/neutron/+/88177111:24
rubasovralonsoh, mlavalle: hi, I believe my deputy week would start 17th of July, however I have PTO planned for that week, would you maybe swap your deputy week with me?11:41
ralonsohrubasov, let me check11:41
ralonsohrubasov, yes (I need to update the dates)11:42
ralonsohI can swap with you, no problem11:42
rubasovralonsoh: cool, thanks11:42
rubasovralonsoh: to be sure: 17th of July will be yours then and 24th of July mine11:43
ralonsohrubasov, yes, actually I'm in PTO starting the 24th, so perfect11:43
rubasovall good then, thank you!11:44
ykarelsondx25, ack i didn't read that in detail11:51
ykarelContinuity, i didn't find 22.10 tag in ovn, may be you refering ubuntu kinetic 22.10?11:57
ykarelif yes then that doesn't seem to have that fix12:00
Continuityykarel: sorry, so looking in the ovn container we are running 22.09.112:04
Continuityi think you are right though, we are seeing vlan fip ports ending up centralised, rather than being distributed. 12:04
Continuitywe are planning an upgrade for later this week/early next12:04
ykarelContinuity, ack 22.09.1 that fix is not there12:12
Continuityi think though that 22.09.1 is the latest available on ubuntu jammy12:14
opendevreviewLajos Katona proposed openstack/neutron stable/2023.1: Delete sg rule which remote is the deleted sg  https://review.opendev.org/c/openstack/neutron/+/88746412:23
ykarelubuntu jammy i see is 22.03.2, so you seems to be on kinetic12:24
ykarelhttps://packages.ubuntu.com/kinetic-updates/ovn-central12:24
opendevreviewLajos Katona proposed openstack/neutron stable/zed: Delete sg rule which remote is the deleted sg  https://review.opendev.org/c/openstack/neutron/+/88746512:25
opendevreviewLajos Katona proposed openstack/neutron stable/yoga: Delete sg rule which remote is the deleted sg  https://review.opendev.org/c/openstack/neutron/+/88746612:25
opendevreviewLajos Katona proposed openstack/neutron stable/xena: Delete sg rule which remote is the deleted sg  https://review.opendev.org/c/openstack/neutron/+/88746712:26
opendevreviewLajos Katona proposed openstack/neutron stable/wallaby: Delete sg rule which remote is the deleted sg  https://review.opendev.org/c/openstack/neutron/+/88746812:26
grami[m]Hi all I wonder if someone could help me understand why a bug that was fixed in Ussuri and wallaby but somehow is no longer in the zed release https://bugs.launchpad.net/neutron/+bug/1920976 12:29
grami[m]I'm going to make a cherry-pick for it now as this should have been placed in zed12:31
opendevreviewGraeme Moss proposed openstack/neutron stable/zed: [OVN] Migrate "reside-on-redirect-chassis" for distributed FIP  https://review.opendev.org/c/openstack/neutron/+/88746912:39
opendevreviewGraeme Moss proposed openstack/neutron stable/zed: [OVN] Migrate "reside-on-redirect-chassis" for distributed FIP  https://review.opendev.org/c/openstack/neutron/+/88746912:40
grami[m]Could I ask if some one could review ^^ please please12:41
opendevreviewGraeme Moss proposed openstack/neutron stable/zed: [OVN] Migrate "reside-on-redirect-chassis" for distributed FIP  https://review.opendev.org/c/openstack/neutron/+/88746912:43
opendevreviewGraeme Moss proposed openstack/neutron stable/zed: [OVN] Migrate "reside-on-redirect-chassis" for distributed FIP  https://review.opendev.org/c/openstack/neutron/+/88746912:48
ralonsohgrami[m], you should first check https://review.opendev.org/c/openstack/neutron/+/87845012:50
ykarelyeap ^ i was looking for, it's reimplemented differently now12:52
ykarelralonsoh, i need to go out, so would be unavailable in today's meeting12:52
ralonsohykarel, no problem, thanks!12:52
opendevreviewMerged openstack/neutron master: Don't allow deletion of the router ports without IP addresses  https://review.opendev.org/c/openstack/neutron/+/88698312:53
opendevreviewyatin proposed openstack/neutron stable/2023.1: Disable pool recycle in tests  https://review.opendev.org/c/openstack/neutron/+/88761012:54
grami[m]Thanks :) yeah this is confusing. Because with a DVR and FIP I have to force the internal port from true to false. 12:55
opendevreviewyatin proposed openstack/neutron stable/zed: Disable pool recycle in tests  https://review.opendev.org/c/openstack/neutron/+/88761112:55
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2023.1: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88760013:27
opendevreviewRodolfo Alonso proposed openstack/neutron stable/zed: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88760113:29
opendevreviewRodolfo Alonso proposed openstack/neutron stable/yoga: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88760313:32
opendevreviewRodolfo Alonso proposed openstack/neutron stable/xena: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88760513:32
opendevreviewRodolfo Alonso proposed openstack/neutron stable/wallaby: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88760613:50
ralonsohPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki 14:00
ralonsoh#startmeeting networking14:00
opendevmeetMeeting started Tue Jul  4 14:00:09 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'networking'14:00
ralonsohhello all14:00
obondarevhi14:00
elvirahi o/14:00
ralonsohrubasov, slaweq, lajoskatona?14:01
lajoskatonao/14:01
bcafarelo/14:01
rubasovo/14:01
slaweqo/14:01
slaweqsorry for being late14:01
ralonsohnp14:01
ralonsohok, let's start (US folks are celebrating today)14:01
ralonsoh#topic annoucements14:02
ralonsoh#link https://releases.openstack.org/bobcat/schedule.html14:02
ralonsohand finally we are in Bobcat-214:02
ralonsoh#link https://releases.openstack.org/bobcat/schedule.html#b-214:02
ralonsohAnd we have the corresponding "releases" patches14:02
ralonsoh#link https://review.opendev.org/c/openstack/releases/+/88749914:02
ralonsoh#link https://review.opendev.org/c/openstack/releases/+/88749214:03
ralonsohand today we have merged the requirements patch for n-lib 3.7.014:03
lajoskatonatoooo much information :-)14:03
ralonsohyeah hehehe (I have more...)14:03
ralonsohrelated to these "releases" patches, there are other 2 that should have your attention14:04
ralonsohthe first ovn-bgp-agent release14:04
ralonsoh#link https://review.opendev.org/c/openstack/releases/+/88738514:04
lajoskatona\o/14:04
ralonsohand the EOL of n-odl in Ussuri (because the CI is broken)14:04
ralonsoh#link https://review.opendev.org/c/openstack/releases/+/88715214:04
ralonsohso please, after this meeting check these ^^ patches and vote14:04
ralonsohthanks!14:04
ralonsohsomething else you want to add?14:05
ralonsohok, let's go for the bugs14:05
ralonsoh#topic bugs14:05
ralonsohlast week report is from haleyb 14:06
ralonsoh#link https://lists.openstack.org/pipermail/openstack-discuss/2023-July/034314.html14:06
ralonsohfirst of all, thanks for your collaboration opening and solving bugs in Neutron14:06
ralonsohthe report is full of them! but most of them already addressed14:06
ralonsohso, again, thank you all!14:06
ralonsohthe only one that is not addressed is 14:06
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/202541014:07
ralonsohhaleyb, "reproduced" this issue but actually what we find in the qroute namespace is the stale arp entry14:08
ralonsohand I think that's ok (??). Should we manually remove the arp entry?14:08
ralonsohok, next week I'll ping haleyb about this one, to have more feedback14:10
slaweqI'm not sure but I think we were adding manually some arp entries in dvr routers in the past14:10
ralonsohhe investigated this one and he could maybe provide a resolution14:10
ralonsohlet me check14:10
ralonsohI only see that in DVR routers14:11
obondarevfor FIPs, right?14:11
ralonsohnot really, these are the fixed_ips14:12
slaweqhttps://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr.py#L4614:12
ralonsoh^^ exactly14:12
slaweqit's like that even in master14:13
obondarevah, I see14:13
ralonsohwhat is the name of the dvr router namespace in the compute nodes?14:13
slaweqbut maybe it's not really called in master anymore14:13
slaweqralonsoh it's just qrouter-XXX14:13
ralonsohok yes, snat is for networker node14:14
slaweqyes14:14
ralonsohok, I'll check with Brian and I'll try to reproduce it too locally14:14
slaweqand for FIPs there is fip-<network_id> namespace also14:14
slaweqon computes14:14
ralonsohanyway, we can continue the investigation offline14:15
ralonsohdo you have any other bug to bring to this section?14:16
ralonsohthis week amotoki is the deputy, next week will be mlavalle14:16
ralonsohok?14:16
ralonsohI'll ping amotoki later today (or I'll send him a mail)14:17
ralonsohnext section14:17
ralonsoh#topic os-ken14:17
ralonsohI think you already know we are moving away from storyboard14:17
lajoskatonagood to hear14:18
ralonsohmy question is about the content of https://storyboard.openstack.org/#!/page/about14:18
ralonsohand related to the second question: do we really need to open a launchpad site?14:18
ralonsohor can we handle the os-ken bugs as n-t-p or n-lib ones, in the same Neutron site14:18
ralonsoh?14:18
lajoskatonaisn't neutron is good to collect these bugs?14:18
lajoskatona+114:19
ralonsohI prefer this option ^14:19
slaweqwe can have os-ken tag14:19
fricklerI'd say neutron is fine, just have a new tag14:19
lajoskatonasounds good with the tag14:19
ralonsohexactly, same as [neutron-lib]14:19
ralonsohso I think it is decided: I'll send a mail just to make this public14:20
ralonsohthank you folks14:20
lajoskatonathanks, good plan14:20
ralonsohalong with that, I've realized that we have some (around 15 patches) pending from ryu to be backported...14:20
ralonsohmy bad...14:20
ralonsohI'll start collecting them and opening the corresponding LP bugs14:20
fricklerralonsoh: what was your question about the about page? I didn't get that14:21
ralonsohto open a https://bugs.launchpad.net/os-ken site14:21
ralonsohbut I prefer to have os-ken bugs in the Neutron bug list14:21
fricklerok, fine then14:22
ralonsohok, so I'll send the mail after this meeting14:22
ralonsohnext topic14:22
ralonsoh#topic specs14:22
ralonsohall pending specs are merged now and we no longer accept new ones (although this is not strictly specified as in Nova project)14:23
ralonsohI need to talk to TC folks to know how to create this milestone, same as Nova14:23
ralonsohin any case, thank you all for your time reviewing14:23
ralonsohnext topic14:24
ralonsoh#topic community_goals14:24
ralonsoh1) Consistent and Secure Default RBAC 14:24
ralonsohslaweq, please14:24
slaweqsure14:24
slaweqthis week we merged https://review.opendev.org/c/openstack/neutron-lib/+/88719114:24
slaweqwhich is needed to move on with service role patch in neutron14:25
slaweqbut I just today realized that it probably breaks some UT https://bugs.launchpad.net/neutron/+bug/202575314:25
slaweqso I need to investigate it first before I will propose new neutron-lib release14:26
slaweqthat's all from my side14:26
ralonsoh(+1 for this periodic job)14:26
ralonsohthanks for the update!14:26
ralonsohbtw, is there a bug/etherpad/link?14:26
slaweqlink for what?14:27
ralonsohfor documentation purposes only14:27
ralonsohfor the service role stuff14:27
ralonsohmaybe you can open a LP bug to track that14:27
slaweqsure14:28
ralonsohperfect! and thanks14:28
ralonsohthe next section if14:28
ralonsohis14:28
ralonsoh2) Neutron client deprecation 14:28
ralonsohlajoskatona, sdk patches are merged14:28
lajoskatonaThe usual ehterpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation14:28
lajoskatonayes one is still waiting for VPN: https://review.opendev.org/c/openstack/openstacksdk/+/88682214:29
ralonsohah, I missed this one14:29
lajoskatonaI will ping sdk folks with it14:29
ralonsohis there a SDK patch in "releases"?14:29
lajoskatonaother than that I started to work on sfc things14:30
ralonsohjust to know if they are going to release them soon14:30
lajoskatonaI realized that api-ref is missing from n-lib: https://review.opendev.org/c/openstack/neutron-lib/+/88719314:30
ralonsoh1600 lines!14:31
lajoskatonaand I pushed wip patches for sdk and neutronclient: https://review.opendev.org/c/openstack/openstacksdk/+/887387 & https://review.opendev.org/c/openstack/python-neutronclient/+/88738814:31
lajoskatonaapi-ref is always a lot of chars :-)14:31
lajoskatonait was hidden in sfc repo, so mostly just copy-paste14:31
ralonsohI'll add all these pending patches to the meeting agenda after this meeting14:32
lajoskatonaack14:32
ralonsohlajoskatona, and again, thanks a lot for your work!14:32
lajoskatonaFrom next week I will be on 2 weeks PTO, so no progress is expected :-)14:32
ralonsohgood to know! enjoy14:33
ralonsohand the last topic for today14:33
ralonsoh#topic on_demand14:33
ralonsohelvira, has one topic14:33
elvirayes :)14:33
elvira Right now there are parameters for certain operations that are not useful depending on the driver. I think it would be sensible to convey to the users that such parameters are not available for the driver they have when they try to use it.14:34
elvirafor example: this arose with the network logging object14:34
elvirawhen you create it, there is a --target parameter that is not useful with the ML2/OVN driver, but it is useful with ML2/OVS14:34
elviraI think this might be the case for many other commands. Right now we just ignore parameters that are not expected. Should we take a more comprehensive approach somehow?14:35
ralonsohhow is the "target" parameter used in ML2/OVS? jsut asking14:36
elviraAn approach I was suggested from our QE folks was to answer with an error through the API, explaining that the parameter is not supported14:36
elviraralonsoh: in ml2/OVS you can target only 1 port, but in OVN you always log per security group14:37
elvirayou cannot tighten the logging to just one port (well, maybe technically you could, by creating 1 security group only for that specific port)14:38
ralonsohdo you have a list of parameters with/without use per mech driver?14:38
lajoskatonathis sounds like driver driven API :-)14:38
ralonsoh^ right and "we don't do this in Neutron"...14:39
elviralajoskatona: That is why I'm asking here, because maybe we could see if there is a way of doing this that is benefitial for the users of all drivers14:39
lajoskatonagood idea, thans for coming with this topic here14:39
ralonsohI think that will depend on the parameter. In this case where a parameter is useless for one mech driver, it could be documented14:39
slaweqone thing I'm affraid of is that we can expose to the regular user details about cloud internals, like backend used14:40
slaweqand I think we shouldn't do that for normal users14:40
ralonsoh^ another reason too14:40
slaweqfor admin only api this may be ok but not for regular user14:40
elviraralonsoh: Another solution could be stating it in the CLI if a parameter is only useful for 1 driver14:41
elviraBut I don't know how of a burden it is right now to change CLI messages14:41
ralonsohexactly, that could be defined in the CLI help14:41
ralonsohthis is easy to be changed in the OSC repo14:41
elviraIsn't this on the deprecated Neutron CLI anymore?14:42
ralonsohno no, not neutronclient14:42
rubasovI also don't see a problem with some drivers returning a "Not Implemented" error14:42
ralonsohopenstackclient14:42
elvirarubasov: Oh, that would keep the API driver-agnostic14:42
ralonsohin this case that maybe (maybe) could be done by the logging manager, listing the loaded drivers14:43
rubasovyeah in that case nobody needs to know what driver is configured in neutron, just that this won't work here...14:43
ralonsohelvira, do you have more parameters? or just this one?14:43
slaweqfor qos we have admin api to list available rules and parameters supported by loaded drivers14:44
elviraralonsoh: right now I only have this one, but talking with bcafarel he explained to me that this is the case for many parameters and the linuxbridge driver14:44
slaweqmaybe we can do something similar for logging api, but for admin only14:44
elviraSo that is mostly why I wanted to talk about it on a general perspective, just in case it was benefitial for more users14:45
elviraAnyway, I can also create a launchpad to continue this discussion 14:45
ralonsohelvira, I think we can't provide a general solution. That will depend on the parameter14:45
elviraif this sounds like a legit problem14:45
ralonsohin this case you have several solution that could be applied in parallel: 1) the CLI help command, 2) the driver listing and 3) the logging manager rejecting the command knowing the loaded drivers (that are only OVS and OVN)14:46
ralonsohso please, open a LP bug to track this and the solutions implemented14:46
elviraralonsoh: ok! thanks a lot for the insights to everyone14:47
elviraI will open it :)14:47
lajoskatona+1 for the bug14:47
ralonsohand that's all I have for today folks, anything else?14:48
opendevreviewSlawek Kaplonski proposed openstack/neutron stable/2023.1: Don't allow deletion of the router ports without IP addresses  https://review.opendev.org/c/openstack/neutron/+/88761414:48
ralonsohin about 10 mins we'll have the CI meeting in this channel14:48
opendevreviewSlawek Kaplonski proposed openstack/neutron stable/zed: Don't allow deletion of the router ports without IP addresses  https://review.opendev.org/c/openstack/neutron/+/88761514:48
ralonsohthank you all!14:48
ralonsoh#endmeeting14:48
opendevmeetMeeting ended Tue Jul  4 14:48:41 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:48
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2023/networking.2023-07-04-14.00.html14:48
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-07-04-14.00.txt14:48
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2023/networking.2023-07-04-14.00.log.html14:48
lajoskatonao/14:48
obondarevo/14:48
rubasovo/14:48
slaweqo/14:48
elvirao/14:49
opendevreviewSlawek Kaplonski proposed openstack/neutron stable/yoga: Don't allow deletion of the router ports without IP addresses  https://review.opendev.org/c/openstack/neutron/+/88761614:49
opendevreviewSlawek Kaplonski proposed openstack/neutron stable/xena: Don't allow deletion of the router ports without IP addresses  https://review.opendev.org/c/openstack/neutron/+/88761714:49
opendevreviewSlawek Kaplonski proposed openstack/neutron stable/wallaby: Don't allow deletion of the router ports without IP addresses  https://review.opendev.org/c/openstack/neutron/+/88761814:49
lajoskatonaslaweq: do we have video meeting today?14:53
slaweqlajoskatona yes14:53
lajoskatonaack, thanks14:54
slaweqping bcafarel, lajoskatona, mlavalle, mtomaska, ralonsoh, ykarel, jlibosva, elvira - CI meeting starting in 1 minute at https://meetpad.opendev.org/neutron-ci-meetings14:59
slaweq#startmeeting neutron_ci15:00
opendevmeetMeeting started Tue Jul  4 15:00:09 2023 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'neutron_ci'15:00
slaweq#link https://meetpad.opendev.org/neutron-ci-meetings15:00
slaweqGrafana dashboard: https://grafana.opendev.org/d/f913631585/neutron-failure-rate?orgId=115:02
slaweq#topic Actions from previous meetings15:02
slaweqralonsoh to remove networking-odl periodic jobs15:02
slaweqralonsoh to check failed test_update_minimum_bandwidth_queue functional test15:03
ralonsoh#link https://review.opendev.org/c/openstack/neutron/+/88759015:03
slaweqslaweq to move LB scenario job to periodic queue15:05
slaweqykarel to send follow up patch for ipv6 job failure15:05
slaweqhttps://review.opendev.org/c/openstack/neutron/+/88714215:06
slaweq#topic Stable branches15:06
bcafarelhttps://bugs.launchpad.net/neutron/+bug/202548615:06
bcafarelfix backports: https://review.opendev.org/q/Id1328d7cba418fa7c227ae9db4fe83c09fd0603515:07
ralonsoh#link https://review.opendev.org/q/Id1328d7cba418fa7c227ae9db4fe83c09fd0603515:07
slaweq#topic Stadium projects15:08
lajoskatonabagpipe fix: https://review.opendev.org/c/openstack/networking-bagpipe/+/88702415:08
slaweq#topic Grafana15:09
slaweqhttps://grafana.opendev.org/d/f913631585/neutron-failure-rate?orgId=115:09
slaweqhttps://review.opendev.org/c/openstack/neutron/+/88696115:14
slaweqhttps://review.opendev.org/c/openstack/neutron/+/88000615:14
slaweq#action ralonsoh to try reduce concurency in functional job(s)15:19
slaweq#topic fullstack/functional15:20
slaweqhttps://ce11c0ee0a74ee8ebb7e-9c035ca54e1e355b36ad4d338836f375.ssl.cf2.rackcdn.com/884474/8/check/neutron-fullstack-with-uwsgi/ac36b87/testr_results.html15:20
slaweq#topic Tempest/Scenario15:21
slaweqhttps://9405e983985bd9b7eb91-5469ab4f5c2741453cb8b95135b2c449.ssl.cf1.rackcdn.com/886982/1/check/neutron-tempest-plugin-openvswitch-iptables_hybrid/2128985/testr_results.html15:21
slaweqhttps://ccc35cfa38f56032f297-95ab28bd06b01f2c7089eb38812248e0.ssl.cf2.rackcdn.com/860766/17/check/neutron-ovs-tempest-dvr-ha-multinode-full/8993e46/testr_results.html15:23
slaweq#topic Periodic15:25
slaweqopenstack-tox-py310-with-neutron-lib-master15:25
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Fix port for Load Balancer Health Check for FIP  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/88660315:26
slaweq#endmeeting15:29
opendevmeetMeeting ended Tue Jul  4 15:29:33 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:29
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-07-04-15.00.html15:29
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-07-04-15.00.txt15:29
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-07-04-15.00.log.html15:29
fricklerralonsoh: regarding os-ken, I was thinking about a LP tag instead of a subject tag, since one can filter notification based on it, like e.g. l3-bgp and dns are currently used. not sure though if end users should care/know about that or if these tags are to be handled by the bug deputy?15:52
ralonsohfrickler, this tag will be added by the bug deputy15:55
ralonsohbut yes, we can add this tag too15:55
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2023.1: [FT] Move ``BaseOVSTestCase`` class to concurrency 1 executor  https://review.opendev.org/c/openstack/neutron/+/88763315:57
opendevreviewMerged openstack/neutron master: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88515416:01
opendevreviewMerged openstack/neutron master: Ensure traffic is not centralized if DVR is enabled  https://review.opendev.org/c/openstack/neutron/+/88662616:01
opendevreviewRodolfo Alonso proposed openstack/neutron stable/yoga: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88760316:20
opendevreviewRodolfo Alonso proposed openstack/neutron stable/xena: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88760516:21
opendevreviewRodolfo Alonso proposed openstack/neutron stable/wallaby: [OVN] Prevent Trunk creation/deletion with parent port bound  https://review.opendev.org/c/openstack/neutron/+/88760616:25
opendevreviewRodolfo Alonso proposed openstack/neutron master: WIP == Add a "port" child table "porthardwareoffloadtype"  https://review.opendev.org/c/openstack/neutron/+/88283216:40
opendevreviewMerged openstack/networking-bagpipe master: [sqlalchemy-20]: remove subtransactions=True  https://review.opendev.org/c/openstack/networking-bagpipe/+/88702417:05
opendevreviewMerged openstack/neutron master: [FT] Move ``BaseOVSTestCase`` class to concurrency 1 executor  https://review.opendev.org/c/openstack/neutron/+/88759019:34
opendevreviewMerged openstack/neutron master: [ovn][ipv6] Add some more tests to skiplist  https://review.opendev.org/c/openstack/neutron/+/88714219:34
opendevreviewMiguel Lavalle proposed openstack/neutron master: [PoC][DNM] Router flavors and service type for OVN  https://review.opendev.org/c/openstack/neutron/+/88398822:45

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!