Tuesday, 2026-01-13

opendevreviewBrian Haley proposed openstack/neutron master: Use project_id key in port plugin code  https://review.opendev.org/c/openstack/neutron/+/97298200:10
opendevreviewBrian Haley proposed openstack/neutron master: Use project_id key in port plugin code  https://review.opendev.org/c/openstack/neutron/+/97298200:27
opendevreviewMerged x/whitebox-neutron-tempest-plugin master: Add neutron agents health check  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/97105900:37
opendevreviewRenjing Xiao proposed x/whitebox-neutron-tempest-plugin master: Replace crudini dependency with ConfigParser  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/97228100:58
opendevreviewBrian Haley proposed openstack/neutron master: Use project_id key in port plugin code  https://review.opendev.org/c/openstack/neutron/+/97298202:39
winiciusallan[m]hi neutron! I don't know if it is really a bug, but I'm struggling when trying to deploy a devstack with uplink_status_propagation02:48
winiciusallan[m]in local.conf, I have defined ENABLED_SERVICES with neutron-uplink-status-propagatio so I belive it should execute this line02:49
winiciusallan[m]https://github.com/openstack/neutron/blob/master/devstack%2Fplugin.sh#L4602:49
winiciusallan[m]But it does not work =/. Making some tests, it only works when set explicitly the Q_ML2_PLUGIN_EXT_DRIVERS02:50
winiciusallan[m]I don't know if this is related to the recent patch deprecating lib/neutron. Any input on it? Thanks in advance.02:51
haleybwiniciusallan[m]: i'm leaving for the day, but in the neutron CI jobs when it configures that setting it also adds the "updatable" extension as well. This is the resultant line in ml2_conf.ini02:58
haleybextension_drivers = port_security,qos,tag_ports_during_bulk_creation,uplink_status_propagation,uplink_status_propagation_updatable,dns_domain_keywords,port_trusted02:58
haleyb(it configures other things as well)02:58
haleybi don't know if that is part of your problem02:58
haleybif you look here you can basically see what a test run was like, including the log file from the stack03:00
haleybhttps://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_6f7/openstack/6f7a89ca3ce74c27b657b1851773819e/controller/logs/index.html03:00
winiciusallan[m]in a few words, I can't enable this extension (both uplink_status and its update ext) via ENABLED_SERVICES, but I'll take a look into how neutron CI jobs does that.03:01
winiciusallan[m]maybe I'm missing something03:01
haleybthere is a local.conf there as well03:01
winiciusallan[m]thanks for the help haleyb :)03:02
haleybenable_service neutron-uplink-status-propagation03:02
haleybbut i see the updatable in that file, but not in the enable line03:02
winiciusallan[m]oh, is that the same as doing03:03
winiciusallan[m]ENABLED_SERVICES+=,neutron-uplink-status-propagation?03:03
haleybnot in the local.conf that's there, don't see that, but NETWORK_API_EXTENSIONS is pretty full, almost everything possible03:04
haleybdevstacklog.txt will have the stack log, all the other files are in that dir/subdir03:05
winiciusallan[m]yeah, pretty full. here on my devstack logs, I was able to see the uplink-status-propagation already listed on NETWORK_API_EXTENSIONS, so I believe this should not be the problem03:05
winiciusallan[m]I'll take a look into these logs and try to change here. I'm working on some downstream projects, so I need also to make sure they are working as expected.03:07
winiciusallan[m]thanks agains!03:07
haleybwhen neutron runs tempest tests and has that extension enable, it also always adds -updatable as well03:07
winiciusallan[m]yeah, I'm aware of this. I'll make sure to enable it too.03:09
haleybgood luck!03:09
winiciusallan[m]thanks! good rest for you03:09
opendevreviewyatin proposed openstack/neutron master: [DNM] Check migration ovn  https://review.opendev.org/c/openstack/neutron/+/97282006:34
opendevreviewMerged openstack/tap-as-a-service master: Update zuul jobs and gates definitions  https://review.opendev.org/c/openstack/tap-as-a-service/+/97305707:05
*** EugenMayer4401802 is now known as EugenMayer44018007:16
opendevreviewRodolfo Alonso proposed openstack/tap-as-a-service master: Migrate upper functional job to Python 3.13  https://review.opendev.org/c/openstack/tap-as-a-service/+/97320308:34
opendevreviewRodolfo Alonso proposed openstack/tap-as-a-service master: Remove `neutron-tempest-plugin-tap-as-a-service-wsgi` definition  https://review.opendev.org/c/openstack/tap-as-a-service/+/97320508:36
ralonsohlajoskatona, hello! ^^ trivial patches08:36
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM: Trigger functional tests  https://review.opendev.org/c/openstack/neutron/+/97298608:57
lajoskatonaralonsoh: my eyes on it09:08
ralonsohthanks09:10
opendevreviewAshish Gupta proposed openstack/neutron-tempest-plugin master: Enable ip_allocation extension in neutron-tempest-plugin-openvswitch job  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/96328709:25
opendevreviewRodolfo Alonso proposed openstack/neutron master: Add flag "ovs_create_tap" in the port VIF details  https://review.opendev.org/c/openstack/neutron/+/97203909:39
ykarelralonsoh, can update the testing patch with ^ new config once nova patch is updated09:55
ykarelbut earlier results went fine09:55
ykarelhttps://review.opendev.org/c/openstack/neutron/+/97282009:58
ralonsohykarel, let me check the results of this patch10:04
ralonsohykarel, Sean asked to change the name of the variable to ovs_create_tap10:09
ykarelyeap i saw that10:10
ralonsohI've already commented this update in the nova patch https://review.opendev.org/c/openstack/nova/+/97314910:10
ralonsohand I'll update yours once the nova patch is updated10:10
ykarelok thx10:10
ralonsohsean-k-mooney, hello! I've updated your patch with your comments. I changed the variable name to "ovs_create_tap"10:10
ralonsohI commented that in https://review.opendev.org/c/openstack/nova/+/973149 too10:11
opendevreviewMerged openstack/tap-as-a-service master: Migrate setup configuration to pyproject.toml  https://review.opendev.org/c/openstack/tap-as-a-service/+/96167110:13
ralonsohsean-k-mooney, qq, I'm checking https://review.opendev.org/c/openstack/neutron/+/972820 results. In particular the n-cpu logs. If I'm not wrong, we are setting the "os_vif_tap_creation" variable in Neutron10:33
ralonsohand I see that in the vif-details and also in Nova cpu10:33
ralonsohbut I don't see any "pyroute2 command ..." debug message in n-cpu10:33
ralonsohhttps://565c2121041a93d5fcf8-d836b35cad78146f67690e7764eaf72e.ssl.cf2.rackcdn.com/openstack/b4a302316134416d86d320901bfa55d1/compute1/logs/screen-n-cpu.txt10:34
ralonsohhttps://565c2121041a93d5fcf8-d836b35cad78146f67690e7764eaf72e.ssl.cf2.rackcdn.com/openstack/b4a302316134416d86d320901bfa55d1/controller/logs/screen-n-cpu.txt10:34
opendevreviewRodolfo Alonso proposed openstack/neutron master: [DNM] Check migration ovn  https://review.opendev.org/c/openstack/neutron/+/97282010:35
opendevreviewMerged openstack/networking-sfc master: reno: Update master for unmaintained/2024.1  https://review.opendev.org/c/openstack/networking-sfc/+/96565810:49
opendevreviewMerged openstack/neutron-dynamic-routing master: reno: Update master for unmaintained/2024.1  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96567210:57
opendevreviewMerged openstack/neutron-vpnaas-dashboard master: reno: Update master for unmaintained/2024.1  https://review.opendev.org/c/openstack/neutron-vpnaas-dashboard/+/96571411:00
opendevreviewRodolfo Alonso proposed openstack/neutron master: Add flag "ovs_create_tap" in the port VIF details  https://review.opendev.org/c/openstack/neutron/+/97203911:41
sean-k-mooneyralonsoh: ill take a look. i just got the first version ready beofre i fisnihed yesteday so ill double check the os-vif part and the debug messages. i wrote the nova code so it could work iwth an older os-vif with the intent of bumping the min version later so i woudl double check in your env if you have properly pip installed the os-vif lib into your devstack env or if its11:53
sean-k-mooneyusing it form pypi11:53
ykarelsean-k-mooney, its using from master/your patch11:56
sean-k-mooneyack. the last thing i got done yesterday was stackign a second compute so ill be testign this and fixing any issue i find today. i got as far as confirming the xml generation was correct yesterday but not that the os-vif code worked end to end so ill be confirming that shortly.11:57
ykarelatleast it worked in ci tests, live migration tests were failing before and now passing so atleast it worked11:58
sean-k-mooneyi have mostly been using the unit/fucntional test to develop this until now11:58
ykarelJan 13 07:17:45.830719 npda4806d5aebc4 nova-compute[86596]:       <target dev="tapa23aeb6a-40" managed="no"/>11:58
sean-k-mooneycool11:58
sean-k-mooneyon my patch i had not got around to modifying the nova jobs to enable it yet11:59
sean-k-mooneybut i see ye hava a dnm that is pulling everything together11:59
ykarelyeap11:59
sean-k-mooneyah you even have   required-projects:12:00
sean-k-mooney              - openstack/os-vif12:00
ralonsohsean-k-mooney, ok so os-vif is creating the tap12:00
sean-k-mooneyits very easy to overlook that12:00
ralonsohwhy is not printing the pyroute2 debug logs?12:00
sean-k-mooneywe may have a log filter12:00
ralonsohahh ok12:00
sean-k-mooneyill double check but we sometiems drop non nova modules like privsep down to info even in debug mode by default12:01
sean-k-mooneyare you seeing other debug logs form os-vif12:02
sean-k-mooneyso no we are not modifying os-vif or pyrout2 https://github.com/openstack/nova/blob/master/nova/config.py but it might not be cofnigured to debug12:03
ralonsohsean-k-mooney, the plug/unplug operations only12:03
sean-k-mooneyright but that os-vif logging right 12:03
sean-k-mooneyas in debug statements in os-vif12:03
ralonsohyes12:04
sean-k-mooneyi dont rememebr seeign debug statemes form pyrout2 in the past12:04
sean-k-mooneycould neutron be enabling logging form it expcitly that nova is not?12:04
ralonsohbut these are just debug messages in the same project12:05
ralonsohok no, these are on os_vif/internal12:05
sean-k-mooneyjust so we are on the same page which specific ones are you looking for?12:06
ralonsohthis is not strictly os_vif/vif_plug_ovs12:06
ralonsohsean-k-mooney, https://github.com/openstack/os-vif/blob/master/os_vif/internal/ip/linux/impl_pyroute2.py#L3012:06
ralonsohI was expecting all pyroute2 commands to be logged (in debug)12:07
sean-k-mooneyah all ip link command got it12:07
sean-k-mooneyso ya that shoudl print rom this invocation https://review.opendev.org/c/openstack/os-vif/+/971231/2/os_vif/internal/ip/linux/impl_pyroute2.py#11712:08
sean-k-mooneywere you looking at the DNM or my change or your local install?12:09
sean-k-mooneyin my patch the neutron config option is not set so we woudl not see it create teh patch12:09
sean-k-mooney*the tap12:09
sean-k-mooneyin the dnm i defintlly expect to see that print12:10
ralonsohsean-k-mooney, the DNM patch12:10
ralonsohyes, I was looking for that, the tap creation checking the pyroute2 logs12:10
opendevreviewRenjing Xiao proposed x/whitebox-neutron-tempest-plugin master: Replace crudini dependency with ConfigParser  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/97228112:11
ralonsohOk, now I see the "critical" part for libvirt: conf.managed = "no"12:12
ralonsohas Yatin mentioned12:12
sean-k-mooneyya so if that there and the tempest test ran any fo the connectivity test that ssh in12:14
sean-k-mooneywe knwo that the tap was added and created by something other hten libvirt12:14
sean-k-mooneybut i dislike that i don tsee thsoe logs so im going to dig a bit deeper12:14
sean-k-mooneyit realy does fell like a log config issue12:15
sean-k-mooneyso perhaps an existing bug we shoudl fix12:15
opendevreviewRodolfo Alonso proposed openstack/tap-as-a-service master: Migrate upper functional job to Python 3.13  https://review.opendev.org/c/openstack/tap-as-a-service/+/97320312:15
opendevreviewRodolfo Alonso proposed openstack/tap-as-a-service master: Remove `neutron-tempest-plugin-tap-as-a-service-wsgi` definition  https://review.opendev.org/c/openstack/tap-as-a-service/+/97320512:15
ralonsohsean-k-mooney, I remember (from years ago) that the namespace was different (vif_plug_ovs vs os_vif)12:16
ralonsohthat could be the problem12:16
sean-k-mooneythat is for the config options12:17
sean-k-mooneyit shoudl not impact logging12:17
sean-k-mooneyit might change teh module path we log form but pyrout2 shoudl still be printed12:17
sean-k-mooneyare we invoking this form privsep?12:21
ralonsohwe should be doing that12:22
sean-k-mooneyit looks like no12:22
ralonsohlet me check12:22
sean-k-mooneyi know the logging is a little weird when we do that12:22
sean-k-mooneynova does filter out all debug logs form privsep invocations12:23
sean-k-mooneybecause we do not want to print thing liek the vms console to the logs12:23
sean-k-mooneyhttps://review.opendev.org/c/openstack/os-vif/+/971231/2/vif_plug_ovs/linux_net.py#9312:25
sean-k-mooneyya we are12:25
sean-k-mooneyso the invocation is happening in the privsep deamon process not novas12:25
sean-k-mooneyand we are filterign debug logs form privsep12:25
ralonsohso this is why we don't log anything else inside the call12:25
sean-k-mooneyi belive so12:25
ralonsohfor sure12:26
ralonsohI think we are doing that to create a single call to privsep12:26
sean-k-mooneywe coudl over ried that in nova's cofnig 12:26
ralonsohthat actually doesn't improve too much the performance12:26
ralonsohit could be better to add the privsep decorator to each pyroute2 command12:26
sean-k-mooneypoteirally but they woudl then be usign a diffent privsep context12:27
ralonsohthe overhead of calling several times to privsep (with daemon) is minimal12:27
ralonsohno no, we have a daemon running (I think so in n-cpu)12:27
sean-k-mooneywhich woudl be ok i think but we woudl be changing form the privsep context form the ovs plugin to the one for the internal code12:28
ralonsohso this is just a matter of sending the command via socket12:28
ralonsohyes and that implies a huge refactor12:28
sean-k-mooneyno what im sayign is we have multipel privsep conftext in os-vif12:28
sean-k-mooneyand multipel deamons as a result12:28
ralonsoh?12:28
sean-k-mooneybut that somethign we could refactor12:28
sean-k-mooneyhttps://github.com/openstack/os-vif/blob/master/vif_plug_ovs/privsep.py12:29
sean-k-mooneyos-vif does not use nova's privsep instance12:29
sean-k-mooneyeach plugin has its own12:29
ralonsohyes, we have 2 entry points and 2 daemons12:29
ralonsohbut the point is that you already have a running daemon12:29
ralonsohis just a matter of sending a command and waiting for the reply12:29
sean-k-mooneyright but the internal module does not have a privsep context today12:29
ralonsohnope12:30
ralonsohok, understood12:30
sean-k-mooneyso movign the decorator to the interal module method means addign one12:30
sean-k-mooneywhich we can do just in a follow up12:30
sean-k-mooneythe main issue with that is just makign sure we are not nestign them12:30
ralonsohyes, that is a refactor not related to this feature12:31
ralonsohthat could be done after all this feature12:31
ralonsoh(also that's important if we want to backport it somewhere else...)12:31
sean-k-mooneyregardign the loging in general however we proably coudl impove it without doign this12:32
ralonsohfor example?12:32
sean-k-mooneywe coudl add a flag to have os-vif log those debug messages at info level if debug loging is enabeld or soemthign liek that12:32
ralonsohyes but even with that, all debug messages "inside" the privsep call are lost12:33
ralonsohfor example, the "pyroute2 command ..."12:33
sean-k-mooneyim no tsure. i think by default they may be but im not sure if we can redirect them we do get info and above level logs form privsep but its been a while sinc ei looked into this12:34
ralonsohwe can return errors from privsep and then log them12:34
sean-k-mooneybsicaly i dont recall if privsep is redirecting the logging over the unix socket or just loging ot stdout12:34
ralonsohbut nothing from inside will be logged 12:34
sean-k-mooneymaybe as i said its defintlly been a while since i looked at this in detail but i tought there was a way to gfet more back12:35
ralonsohI'm going for lunch now12:36
sean-k-mooneycool12:36
sean-k-mooneyill update my patch for the changes you made and test it locally12:36
sean-k-mooneyenjory o/12:36
lajoskatonahaleyb: Hi, today I can't join the team meeting13:30
haleyblajoskatona: ack, thanks13:44
haleyb#startmeeting networking14:00
opendevmeetMeeting started Tue Jan 13 14:00:21 2026 UTC and is due to finish in 60 minutes.  The chair is haleyb. 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
haleybPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh14:00
bcafarelo/14:00
ralonsohhello14:00
haleybhi everyone14:01
frickler\o14:01
mlavalle\o14:01
haleyb#announcements14:02
haleybWe are in week R-11 of Gazpacho14:02
haleybGazpacho-2 milestone was last week14:02
slaweqo/14:02
haleyblooks like we are still waiting for release patch to merge, then will need requirements bump14:03
haleybso technically if we needed could change neutron hash, but i don't think anything critical has merged14:03
haleyb#link https://releases.openstack.org/gazpacho/schedule.html is the release schedule14:04
haleybthe neutron-lib release patch did merge, but requirements patch is still waiting14:05
fricklerhaleyb: I can approve it right now if you don't want to update. we did successful release tests earlier today14:05
haleybfrickler: yes, thanks14:05
haleyb#link https://review.opendev.org/c/openstack/releases/+/97245714:05
haleybfrickler: when will requirements patches merge? i don't know if the zuul rekeying has impacted that14:06
haleyb#link https://review.opendev.org/c/openstack/requirements/+/97154514:06
ralonsohalso https://review.opendev.org/c/openstack/requirements/+/97269314:07
ralonsohand https://review.opendev.org/c/openstack/requirements/+/97270114:07
fricklerwell that only depends on the requirements team reviewing stuff14:07
haleybralonsoh: and https://review.opendev.org/c/openstack/requirements/+/97269214:08
haleybso we will just have to wait for requirements14:09
haleybJust a reminder to use the priority dashboard for anything neutron/networking related14:10
haleyb#link https://tinyurl.com/59z278km14:10
haleyband add RP +1/+2 to the review as necessary14:10
haleybi need to find otherwiseguy for one of those14:10
haleybReminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers14:11
haleybSo getting back to Gazpacho release, we should be prioritizing any work we have planned for the cycle14:11
haleybfor example the BGP work14:12
haleyb11 weeks will go pretty quickly14:12
haleybG-3 milestone is week of February 23rd14:13
haleybso 6 weeks if i'm counting right14:13
haleybthat was all i had, any other announcements?14:14
haleyb#topic bugs14:14
haleybralonsoh was the bug deputy last week, his report is at14:14
haleyb#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/LYLVMEP3EPS4PXHYFOTZCFID6ZD4H3VX/14:15
haleyband from what i can tell all have been addressed or patches proposed14:15
ralonsohAll is addressed, right14:15
haleybperfect14:16
haleybthis week ichen is the deputy, next week is jlibosva14:16
haleybis that ok for you ichen ?14:16
ichenWorks for me.14:16
haleybgreat14:17
ralonsohfor Jakub too14:17
haleybperfect14:17
haleyb#topic specs14:17
haleyb#link https://review.opendev.org/q/project:openstack/neutron-specs+status:open14:17
haleybwere there any other comments on mlavalle's routed networks spec?14:18
haleyb#link https://review.opendev.org/c/openstack/neutron-specs/+/96633414:18
mlavallenone14:18
ralonsoh(I have it in my review list for tomorrow morning)14:19
mlavalleother than the small nit you pointed out14:19
mlavallethanks ralonsoh 14:19
haleybmlavalle: i would not respin for that14:19
mlavalleI won't14:19
haleybralonsoh: ack, thanks i'll leave it open, you can +W if you like it14:19
ralonsohthanks14:20
haleybthere are other open specs there, will try and go through this week, might be late to get them implemented14:21
haleybok, moving on14:21
haleyb#topic community goals14:21
haleybi know lajoskatona could not attend, will just mention his sdk series14:22
haleyb#link https://review.opendev.org/q/topic:%22sdk_for_neutron%2214:22
haleyball nova changes14:23
haleybone job is failing, but really need some nova eyes on those to move forward14:23
haleybi continue to push patches on project_id migration, thanks for all the reviews14:24
ralonsohthanks for finishing this topic14:25
haleybthere is still plenty of work to do, just getting to actual db/plugin code, and need to do cross-project testing so i don't break anything14:26
ralonsohthat will happen for sure again14:26
ralonsohbut this is why now is the time  to do it14:26
haleyb#link https://review.opendev.org/c/openstack/neutron/+/972982/ is the latest one, but failing one functional test i need to debug14:27
haleybwas going to get to network/subnet/routers next14:27
haleybhopefully i'm doing this all correctly in the plugins...14:28
haleyb#topic on-demand14:29
haleybanything else people want to discuss?14:29
haleybnothing on the agenda14:29
ralonsohno, thanks14:29
fricklerI did look at the n-d-r issue over the weekend14:29
slaweqhaleyb I know it may be a bit of additional work but maybe you could create small patches for stadium projects and set them to be Depends-On on your patches for project_id changes14:29
fricklerand it seems to me like to bug is in the evenlet-removal stuff in os-ken, which seems to be untested so far14:30
slaweqto make sure we are not breaking stadium or if we do, to fix it before neutron changes will be merged14:30
ralonsohfrickler, which part?14:30
fricklerstuff sahid merged a year ago14:30
haleybslaweq: yes, i was going to do that for at least the ones that broke previously, but should also do nova and devstack at a minimum14:30
ralonsohbtw, lajoskatona proposed a patch for os-ken: https://review.opendev.org/c/openstack/os-ken/+/97027714:30
slaweqthx haleyb 14:31
fricklersee the latest comment on https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/95674714:31
ralonsohooook, so the timeout context14:31
ralonsohok, I think this timeout context exception needs some kind of testing14:32
frickleryes, it looks like it never really gets entered14:32
ralonsohand most probably a refactor14:32
ralonsohfrickler, ok, let me propose some tests to check it 14:33
fricklercool, thx14:33
haleybfrickler: thanks for the info14:34
opendevreviewMichel Nederlof proposed openstack/neutron master: Keep virtual ports unbound when binding  https://review.opendev.org/c/openstack/neutron/+/97311514:34
haleybok, any other topics?14:35
slaweqnothing from me14:36
haleybthanks for attending, have a good week everyone14:36
haleyb#endmeeting14:36
opendevmeetMeeting ended Tue Jan 13 14:36:16 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:36
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2026/networking.2026-01-13-14.00.html14:36
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2026/networking.2026-01-13-14.00.txt14:36
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2026/networking.2026-01-13-14.00.log.html14:36
mlavalle\o14:36
slaweqthx, You too14:36
ralonsohbye14:36
opendevreviewMichel Nederlof proposed openstack/neutron master: Make sure virtual ports stay unbound  https://review.opendev.org/c/openstack/neutron/+/97325914:41
ralonsohhaleyb, hello! if you have 1 min: https://review.opendev.org/c/openstack/tap-as-a-service/+/973203/214:46
ralonsohand the upper patch too14:46
haleybralonsoh: ack, and i need to update the release-checklist doc, a lot of these were missed (and not only neutron), not the end of the world of course14:48
mnederlofhaleyb, thanks for your review on https://review.opendev.org/c/openstack/neutron/+/973115; i have created another approach in https://review.opendev.org/c/openstack/neutron/+/973259 could you maybe shine your light on that one too and let me know which approach is the preferred one?14:50
opendevreviewSlawek Kaplonski proposed openstack/neutron-specs master: Remove not necessary spec templates from the releases folders  https://review.opendev.org/c/openstack/neutron-specs/+/97326314:59
mnederlofralonsoh, i´ve added a workflow to reproduce the issue15:00
ralonsohmnederlof, I'll check it now15:01
mnederloftnx15:01
opendevreviewBrian Haley proposed openstack/neutron master: Update jobs to use the periodic zuul job templates  https://review.opendev.org/c/openstack/neutron/+/97273415:38
opendevreviewSlawek Kaplonski proposed openstack/neutron-specs master: Remove not necessary spec templates from the releases folders  https://review.opendev.org/c/openstack/neutron-specs/+/97326315:44
*** jlibosva is now known as Guest3577615:48
winiciusallan[m]haleyb: just for the record, the problem that I was facing yesterday when trying to enable the uplink-status-propagation was solved adding `enable_plugin neutron <url>` to local.conf16:16
winiciusallan[m]thanks again for the neutron CI snippets :)16:17
opendevreviewBrian Haley proposed openstack/neutron master: Update jobs to use the periodic zuul job templates  https://review.opendev.org/c/openstack/neutron/+/97273416:23
opendevreviewMerged openstack/neutron-specs master: Remove not necessary spec templates from the releases folders  https://review.opendev.org/c/openstack/neutron-specs/+/97326318:48
opendevreviewMerged x/whitebox-neutron-tempest-plugin master: [multicast] Only use vlan_transparent option when really required  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/97289919:27
-opendevstatus- NOTICE: An update to one of our base jobs roles broke another base job role. This update has been reverted and jobs should be working again.20:59

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