Thursday, 2026-01-22

opendevreviewchandan kumar proposed openstack/watcher-dashboard master: [poc]Add Playwright-based E2E testing framework  https://review.opendev.org/c/openstack/watcher-dashboard/+/97035304:09
opendevreviewAlfredo Moralejo proposed openstack/watcher master: Revert "Update migration notification"  https://review.opendev.org/c/openstack/watcher/+/97429809:23
opendevreviewDouglas Viroel proposed openstack/watcher master: Deprecate MAAS integration  https://review.opendev.org/c/openstack/watcher/+/97430811:15
opendevreviewJoan Gilabert proposed openstack/watcher master: Add wrapper classes for novaclient objects  https://review.opendev.org/c/openstack/watcher/+/97291211:43
opendevreviewJoan Gilabert proposed openstack/watcher master: Use wrapper classes for novaclient objects  https://review.opendev.org/c/openstack/watcher/+/97291311:43
opendevreviewDouglas Viroel proposed openstack/watcher master: DNM - Eventlet code removal  https://review.opendev.org/c/openstack/watcher/+/97399511:46
dviroelhi all, watcher meeting will start in 7m, please add your topics/reviews/bugs to the agenda: https://etherpad.opendev.org/p/openstack-watcher-irc-meeting11:53
dviroel#startmeeting watcher12:01
opendevmeetMeeting started Thu Jan 22 12:01:08 2026 UTC and is due to finish in 60 minutes.  The chair is dviroel. Information about MeetBot at http://wiki.debian.org/MeetBot.12:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.12:01
opendevmeetThe meeting name has been set to 'watcher'12:01
dviroelhey o/  12:01
rlandyo/12:01
morenodo/12:01
jgilabero/12:01
amoralejo/12:01
dviroelcourtesy ping list: sean-k-mooney chandankumar12:02
dviroelthanks for joinning folks o/12:02
dviroellet's start with today's meeting agenda12:02
dviroel#link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L2812:03
dviroelfeel free to add your own topics to the agenda12:03
rlandychandankumar is away today12:03
dviroelrlandy: ack, tks12:03
dviroel#topic Eventlet removal12:04
dviroeladded a topic for a quick recap on our current status12:04
dviroelwe recently merged the last applier patch, to include threading mode12:04
dviroelall components now support threading mode, and there is a ci job that runs on check against all new proposed patches12:05
dviroelthere is also a job that runs all unit tests with python3.1212:05
dviroelI recently proposed a DNM patch to remove all eventlet code12:06
dviroeland see how it goes in our CI jobs12:06
dviroel#link https://review.opendev.org/c/openstack/watcher/+/97399512:06
dviroelthe PS1 was green, but was still missing MAAS eventlet code removal12:06
dviroelthe PS2 now has everything removed and we will see ci results soon12:07
dviroeland talking about MAAS12:07
dviroeli just pushed the deprecation of MAAS integration12:08
dviroel#link https://review.opendev.org/c/openstack/watcher/+/97430812:08
dviroelif nobody fix its implementation in the following releases, we will need to delete the code, together with eventlet code12:08
dviroelso it is important to deprecated in this release12:09
dviroeli would also like to request some reviews on 12:09
dviroelpatch: Remove eventlet-based timeout in CDM collectors: https://review.opendev.org/c/openstack/watcher/+/968568 12:10
dviroeldue to the removal of eventlet timeout based implementation, there is a proposal for adding new timeouts inside nova's collector code, using futurist waiters12:10
dviroelthanks all that already reviewed12:11
dviroeland finally12:11
dviroeljust to mention what would be the next big thing in the eventlet removal12:11
dviroelhttps://bugs.launchpad.net/watcher/+bug/2133505 ([RFE] Enable Applier to run Taskflow parallel engine with native threads)12:11
dviroelthis RFE summarize the need for a parallel engine execution when running native threads12:12
dviroelthis is important to have before removing eventlet implementation12:12
amoralejit's the last issue to fix for eventlet, right?12:12
dviroelyeah, I think so12:13
amoralejgood12:13
dviroelbut it can turn to be very complicated12:13
amoralej:(12:13
dviroel:/12:13
jgilaberthanks for the great work dviroel++12:14
dviroel:)12:14
dviroelany other questions/comments in that topic?12:14
amoralejyep dviroel++ this was a hard one12:14
dviroelok, next topic then12:15
dviroel#topic Reviews12:15
dviroelchandankumar is out, but he left some changes for us12:15
dviroelAdd spec for improving watcher-dashboard testing with selenium vs playwright comparison based on poc12:16
dviroel#link https://review.opendev.org/c/openstack/watcher-specs/+/970220 12:16
dviroelit seems that was just a recent move to the 2026.2 directory12:16
dviroelthere is also a link to the recent poc12:17
dviroel#link https://review.opendev.org/c/openstack/watcher-dashboard/+/970353 (playwright poc)12:17
dviroelso i guess that we could review and early merge this 2026.2 spec12:17
dviroelnext12:17
dviroel973806: Backport of three nodeset for realdata to stable/2025.212:18
morenodthats me12:18
dviroel#link https://review.opendev.org/c/openstack/watcher/+/97380612:18
morenodlast week we merged on master, and it was fine during the CI on the weekend12:18
dviroeloh nice12:18
morenodbut this CI also runs on 2025.2, so we need this backport12:18
dviroelack, I can do a review after the meeting and get this in12:19
morenodit also runs on the weekend, so if we can it merged today or tomorrow, we will see the results on monday12:19
amoralejmaster jobs have been passing consistently after that change?12:19
morenodthere is only one run12:19
morenodbut yes12:19
amoralejfor periodic real-data jobs i mean12:19
amoralejit was consistently failing before, so i guess that's a good sign :)12:20
sean-k-mooneyo/12:20
dviroelok, the next review then is 12:21
dviroelLast pending patch of the applier-monitor series (comments are fixed in last PS)12:21
dviroel#link https://review.opendev.org/c/openstack/watcher/+/97061412:21
dviroelthis one is on my list for today12:21
amoralejyes, that comes from the service monitors one, i hope it has all the requested fixes, thanks!12:21
jgilaberme too, I'll get to that later today, but it was almost ready when I first reviewed12:22
dviroelack, any other review requests?12:23
amoralejI have one but it's related to one of the bugs in the list, so we can cover it there12:23
dviroelack12:23
dviroel#topic Bugs12:23
dviroeli added 3 bugs to the etherpad today12:23
dviroelDataModel is not updated properly after live migrations with notifications - NEW12:24
dviroel#link https://bugs.launchpad.net/watcher/+bug/2138857 12:24
dviroelthis one amoralej ^?12:24
amoralejyes, that's the one i reported today12:25
dviroeli remember someone raising a similar issue in another old bug12:25
amoralejso, while testing locally i found some unexpected behaviors when notifications were enabled12:25
amoralejme too, but i couldn't find it, tbh12:25
amoralejI sent patch https://review.opendev.org/c/openstack/watcher/+/97429812:25
amoralejsurprisingly, it was fine when notifications were introduced but then event for live migration end was changed in https://review.opendev.org/c/openstack/watcher/+/658973 and broken12:26
amoralejor something has changed in the nova notifications since then, dunno12:26
amoralejbut what i find checking at the notifications payload is that instance.live_migration_post_dest.end is the correct event to consume12:27
amoralejyou can see the full payloads in the lp12:27
dviroelok, i can also double check that during reviews12:28
amoralejthanks12:28
dviroeland this only happens with live migration?12:28
amoralejyes, only affects live migrations12:28
amoralejthe actual issue is that the model is wrongly updated on live-migrations12:29
amoralejit's fixed in the following periodic sync12:29
dviroeloh ok12:29
amoralejbut there is a time gap where the host assigned to the vm is wrong12:29
dviroelthanks for reporting and quickly providing a fix12:30
dviroeli will take a look with more time12:30
amoralejthat will deserve backport imo btw12:30
dviroelsure12:30
dviroelany other comments wrt this bug?12:31
dviroelnext one 12:31
dviroelRace condition in ONESHOT Audit cancel workflow12:32
dviroel#link https://bugs.launchpad.net/watcher/+bug/2134046 12:32
dviroelah! I remember this one12:32
amoralejyes, we discussed that some time ago12:32
dviroelit happens sometimes in CI, depending how the test is written in tempest12:33
amoralejand the infra load, as it's race condition12:33
dviroelI can confirm that it happens yes12:33
dviroelpriority for this one?12:33
amoralejChandan mentioned he would work on it in https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/96936612:35
amoralejwhich btw, i think workarounds it12:35
jgilaberI think high, since we encouter it from time to time in ci12:35
amoraleji think it will not affect real world users12:35
dviroelyeah12:36
jgilaberalthough medium would also make sense since it's not consistent12:36
amoralejthat's why we didn't prioritize it too much12:36
amoralejbut yeah, it's a pain in ci12:36
dviroeli would say that is a Low, it is just a annoying in ci 12:36
dviroelin the end, it will really execute the oneshot audit, that was previously cancelled12:36
dviroelbut it is indeed a nice to have12:37
amoralejonly happens if you try to cancel a oneshot audit righ after creating it and before going into ONGOING which is usually just a very short time interval12:37
dviroelbtw, s/Priority/Importance12:37
amoralejcorrect, it's valid bug under certain circumpstances12:37
dviroellow or medium in this case?12:37
amoralejmedium :)12:38
dviroelok12:38
amoralejI proposed a couple of alternatives, btw, i think the one to follow is making the decision-engine to validate that the audit is not CANCELLED before moving it to ONGOING.12:38
dviroelack12:39
jgilaber+1 to that12:39
amoralejif we don't fix it, i'd be in favor of mergint the workaround https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/969366 to at least fix the ci12:39
jgilaberit should fix the problem and have less implication than the alternative12:39
amoraleji mean, if we don't fix it soon12:40
dviroelok, so amoralej you have the assignee of this one :) 12:40
dviroelack12:40
amoralejok, no problem :)12:40
dviroelso the next bug in the list12:41
dviroelResource name is not required in the schema of the change_nova_service_state action12:41
dviroel#link https://bugs.launchpad.net/watcher/+bug/213319912:41
dviroelthis one is there for a while12:41
jgilaberyes, I opened this one while reviewing amoralej's patch documenting the existing actions12:43
jgilaberthe action schema and code are not in sync12:43
jgilaberthe action uses resource_name unconditionally but it's not required in the spec12:44
jgilabers/spec/schema12:44
amoralejalso, we have duplicated information there, resource_id and resource_name iirc. we should rely only in one12:45
jgilaberthere is also a comment by sean-k-mooney  in the bug pointing to the action using an old compute api12:45
jgilaberI have not digged into the action code12:45
dviroelgot it, it is something that needs to be fixed12:46
dviroelbut we don't see any failures today because the code itself is configuring these parameters?12:46
dviroelit could be an issue when user creates its own actions with the actuator?12:47
amoralejyes12:47
amoralejin the existing strategies, it's always using resource_name and resource_id, and the action only uses resource_name12:48
jgilaberfor example the host maintenance strategy sets both https://github.com/openstack/watcher/blob/8a884e3d5166678b85eaf264e518ef24b30085e5/watcher/decision_engine/strategy/strategies/host_maintenance.py#L16512:48
jgilaberso it won't cause a problem12:48
sean-k-mooneythe schema and code are restricign uscase that nova supprots12:48
amoraleji.e. https://github.com/openstack/watcher/blob/4f17759e794d2f07e7ae209f1f07f4e79733db1d/watcher/decision_engine/strategy/strategies/host_maintenance.py#L163-L18012:48
sean-k-mooneyso resouce_name in at leas some cases shoudl nto be requried12:48
sean-k-mooneybut we woudl need to change the implemation to make that work if i recall12:49
amoralejfor me, the questions is if we should always use resource_id and remove resouce_name12:49
amoralejyes, it needs changes in the implementation12:49
sean-k-mooneywhen calling nova proably but we dont nessisarly want to change our inputs to the stragies to requrie that12:50
sean-k-mooney the hostname in nova orgianlly (i mean up until train ish) didnt offically supprot using FQDNs12:51
sean-k-mooneytriplo was abusing a gap in our validation for year before we offically suprpoted that12:51
sean-k-mooneyhost names were requrie e to be gobally uniq12:52
sean-k-mooneyin some case however i.e. multie cell deployments12:53
sean-k-mooneyit was possibel to have 2 compute with the same service name but diffent uuids12:53
amoralejso, one more reason to use the uuid i guess12:53
sean-k-mooneynow that wont happen in our product and we tell peopel to either use an FQDN now or a globlly unque host name12:53
sean-k-mooneywell im mostly saying in practic today people knwo to either make the short host name unique or use the fqdn12:54
sean-k-mooneyso its a factor but we coudl just say dont do that if we ahve a case where tehy conflict12:54
sean-k-mooneyanyway we likely shoudl accpet either value but require that one of the 2 is set and prefer the uuid over the name where the uuid is aviable in most cases12:56
dviroelhow do we proceed with this LP? 12:57
jgilaber+1 to that12:57
dviroelfix the schema as mentioned?12:57
dviroeland open a RFE based on sean's comment #1?12:57
dviroelto update the code to use the correct nova api12:57
sean-k-mooneywell i woudl consider comment 1 to be a bugfix not an RFE12:58
sean-k-mooneyi.e. just internally useing a diffent nova api is not a feature if it does nto break exisitng exteral interaction12:58
sean-k-mooneymy perference is to not change the schema and to modify the code to work when resouce name is not provided12:59
amoralejand when it's provided, what'd be the expected behavior?13:00
amoralejwhich one would be used?13:00
sean-k-mooneyif both are there the uuid if only the resouce name we would retrive the uuid form our compute model and use the uuid13:01
amoralejso resource_name wins13:01
sean-k-mooneyi mean it depns on if we are talkign about runing the action via the acturator stagey where we specify the action directly13:01
amoralejah, sorry, the resource_id is mandatory13:01
amoralejthat was my point13:01
sean-k-mooneyor if we are talking about internally13:01
sean-k-mooneyintallay i think we shoudl move to exlusively usign the uuid13:02
amoralej^ that was my preference too13:02
amoralejsaid that, imo this is low13:03
sean-k-mooneyso the decion engine shoud exclusivley create actions using resouce_id going forward13:03
sean-k-mooneyya this is a latenet bug low is ok13:03
sean-k-mooneymedium would be fine too13:03
dviroelack, i will update the LP and link our logs there13:04
dviroelanything else to discuss?13:04
dviroelwe are already overtime13:04
dviroelchandankumar will chair next week meeting 13:05
dviroellet's wrap up13:05
dviroelwe will meet again next week13:05
dviroelthank you all for participating13:05
dviroel#endmeeting13:05
opendevmeetMeeting ended Thu Jan 22 13:05:44 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:05
opendevmeetMinutes:        https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-01-22-12.01.html13:05
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-01-22-12.01.txt13:05
opendevmeetLog:            https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-01-22-12.01.log.html13:05
opendevreviewDavid proposed openstack/watcher stable/2025.2: Move real data jobs nodeset to three nodes (two computes + 1 controller)  https://review.opendev.org/c/openstack/watcher/+/97380615:21
dviroeljgilaber: if you are still around, pls revote ^17:07
jgilaberdon17:15
opendevreviewJoan Gilabert proposed openstack/watcher master: Add wrapper classes for novaclient objects  https://review.opendev.org/c/openstack/watcher/+/97291217:17
opendevreviewJoan Gilabert proposed openstack/watcher master: Use wrapper classes for novaclient objects  https://review.opendev.org/c/openstack/watcher/+/97291317:17
opendevreviewMerged openstack/watcher stable/2025.2: Move real data jobs nodeset to three nodes (two computes + 1 controller)  https://review.opendev.org/c/openstack/watcher/+/97380618:58
opendevreviewMerged openstack/watcher master: Homogenize ActionPlans cancel behavior in threading and eventlet mode  https://review.opendev.org/c/openstack/watcher/+/97327419:24
opendevreviewDouglas Viroel proposed openstack/watcher-specs master: Add spec for Audit Pipeline feature  https://review.opendev.org/c/openstack/watcher-specs/+/96984019:51

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