Thursday, 2026-05-14

opendevreviewchandan kumar proposed openstack/watcher-specs master: Add spec for improving watcher-dashboard testing  https://review.opendev.org/c/openstack/watcher-specs/+/97022007:26
opendevreviewchandan kumar proposed openstack/watcher-specs master: Add spec for improving watcher-dashboard testing  https://review.opendev.org/c/openstack/watcher-specs/+/97022007:26
opendevreviewchandan kumar proposed openstack/watcher-dashboard master: Add Playwright-based E2E testing framework  https://review.opendev.org/c/openstack/watcher-dashboard/+/97035307:40
opendevreviewchandan kumar proposed openstack/watcher-dashboard master: Add Playwright integration test for skip action workflow  https://review.opendev.org/c/openstack/watcher-dashboard/+/97659407:41
opendevreviewTakashi Kajinami proposed openstack/watcher master: Drop reference to legacy keystonemiddleware options  https://review.opendev.org/c/openstack/watcher/+/98859610:42
*** jgilaber__ is now known as jgilaber10:58
jgilaberHi! Reminder that the IRC meeting will start in ~ 1 hour, feel free to add your topics to the agenda https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L3110:58
opendevreviewTakashi Kajinami proposed openstack/watcher master: Drop reference to legacy keystonemiddleware options  https://review.opendev.org/c/openstack/watcher/+/98859611:18
jgilaber#startmeeting Watcher12:01
opendevmeetMeeting started Thu May 14 12:01:04 2026 UTC and is due to finish in 60 minutes.  The chair is jgilaber. 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
dviroelo/12:01
sean-k-mooneyo/12:01
jgilaberHi everyone! Who is around today?12:01
jgilabercourtesy ping: amoralej chandankumar morenod rlandy12:01
winiciusallan[m]o/12:01
amoralejo/12:01
rlandyo/12:01
jgilaberlet's give a minute before starting12:01
jgilaberin the meantime feel free to add any last minute topic to the agenda https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L3112:01
chandankumaro/12:02
jgilaberok let's start with the first topic12:02
jgilaber#topic Updates on watcher-dashboard UI testing playwright spec12:03
jgilaberchandankumar, go ahead12:03
jgilaber#link Updates on watcher-dashboard UI testing playwright spec12:03
jgilabersorry12:03
jgilaber#link https://review.opendev.org/c/openstack/watcher-specs/+/97022012:03
chandankumarjgilaber: sure12:03
chandankumarFor dashboard ui testing spec, as a first step we have to get playwright requirement patch merge in requirement repo 12:04
chandankumarhttps://review.opendev.org/c/openstack/requirements/+/983421/9#message-30b9c7cdbb579e99737a006aa39a18ef433cd2c6 we are getting pushback on this requirement change12:04
chandankumaras only single project watcher-dashboard is going to use and  UI team is using something else12:04
chandankumarWe got votes from horizon team also having no objection in merging it12:05
chandankumarIn order to move forward with playwright work, We can add playwright to watcher-dashboard side12:05
chandankumarI was trying with test-requirements.txt file but it also requires us to add playwright in requirements project12:05
sean-k-mooneyyes12:06
sean-k-mooneyand that the only path forward to merging the playright code in my opion12:06
chandankumarSo I am now left with one option to add playwright in tox.ini and go forward till someother project stats using it12:06
sean-k-mooneyi dont want to workaorund the reuiqmente project even thoguh its trivial to do so12:06
sean-k-mooneyno12:06
sean-k-mooneyim -2 on that12:06
sean-k-mooneyeither we get this approve via the requireemtn proejct or we abandon the effort12:07
dviroelwhich other project could join us in the playwright adoption? if we have 2 projects using it, it would go from a -1 to a +2?12:07
sean-k-mooneywell any ui project could12:07
amoralejyes, we should get it into the requirements project12:07
chandankumardviroel: if we propose changes to grian-ui then?12:07
sean-k-mooneybut i dont think that actuly the blocker12:08
amoraleji understand the complain is not that nobody else is using it but they perceived lack of consensus12:08
dviroelthe closest seems to be grian-ui yeah12:08
sean-k-mooneyright but the same woudl have been true for pytest12:09
sean-k-mooneyit was added as an optional test runner and then horzon decied to actully use it for writing tests12:09
sean-k-mooneywhich was never inteneded to be allowed12:10
amoralejlast comment from Jan may change the perception from Jens12:10
sean-k-mooneyyep12:10
sean-k-mooneylets give them some tiem and we can follow up next week12:10
chandankumarsure, 12:10
amoralejIt may be good to reopen the conversation, yes12:10
amoralejcomment is just from yesterday12:11
chandankumarI will follow up with Jens next week12:11
jgilaberthanks for the update chandankumar any other comments on this topic?12:11
chandankumarDo requirements team have weekly irc meeting?12:11
chandankumarMay be I will bring playwright there to have more eyes on that12:12
chandankumardviroel: no12:12
dviroeldoesn't seems to have meetings anymore  12:13
dviroelaccording with https://meetings.opendev.org/meetings/requirements/12:13
chandankumaryes, correct.12:14
chandankumarI will follow up with them next week12:14
chandankumarthank you everyone on this topic!12:14
jgilaberack, let's move on to reviews12:14
jgilaber#topic Reviews12:14
jgilaberamoralej, you have the first two12:14
dviroeltks chandankumar for pursuing this effort12:15
amoralej#info  I did a first approach for next step in functional testing12:15
amoraleji got some time to retake the work for functional tests12:15
dviroel++12:15
amoralej#link https://review.opendev.org/q/topic:%22blueprint-functional-test-infrastructure%22+status:open12:15
amoralejin this first patch i create basic infra to run watcher services and run tests with gabbi12:16
amoralejwe can test any api workflow with dummy goal and strategy12:16
amoralejnot external services fixtures yet, that will be next12:17
amoraleji added some workflows in the patch to validate12:17
sean-k-mooneythe gabi api test and the broader fucntional tests are actuly two related but seperate parts12:17
sean-k-mooneywhile the gabi test will be declaritvie12:17
sean-k-mooneythe broader functional test are more imperitive in that they use the normnal way of write tests with unittest12:18
amoralejboth ways are supported in the patch12:18
sean-k-mooneyack12:18
amoralejactually i left tests written in both ways12:18
sean-k-mooneyjust notign we proably wont end up testing say zone migration with gabi and emulating vm migrtion12:18
amoralejso that it can be examples of how to run in both ways12:18
sean-k-mooneyalhtoughw e potitnally could12:19
sean-k-mooneyack12:19
dviroel i didn't review it yet, but +1 for the contributor doc addition :)12:19
amoralejbecause of the requirement to create declarative the model?12:19
amoralej^ i mean why not to use gabbi for zone_migration i.e.12:19
amoraleji'm looking for a way to do it :) 12:20
sean-k-mooneyamoralej: its just not really intended fo rvery complex senairos12:20
sean-k-mooneyi.e. doign the creation of server in nova then callign watcher12:20
amoraleji think as we create more complex tests we will see the limits12:20
sean-k-mooneyyou coudl do that but its really intnded for testign one service12:20
sean-k-mooneyanyway we can see12:21
amoralejyep, we can see12:21
amoralejplease take a look and let me know your thoughts12:21
dviroelack12:21
amoralejlet's move to next one12:22
amoralej#info rephrased docs in https://review.opendev.org/c/openstack/watcher/+/98677712:22
amoralejas discussed last week, i rephrased the docs there12:23
amoralejno need to go into details now or we will get out of time again for other topics, just for awareness :)12:23
dviroelok, thanks, it is on my list for today along with other patches12:24
amoralejunless you want to discuss in detail now, we can move on to next reviews12:24
jgilaberthanks amoralej I think we can move to the next one12:25
jgilaber#link https://review.opendev.org/q/topic:%22bug/2141951%2212:25
jgilaberdviroel, I think this is yours?12:25
dviroelyeah12:25
dviroelthere are a couple of patches propose12:25
dviroelrelated with workload_stabilization strategy improvements12:26
dviroelthere are 3 changes propose in the end12:26
dviroel1) is an improvement in the model locking that we discussed past week12:26
dviroelwhich amoralej already reviwed and pointed some issues in ci that can be related12:26
dviroelor may just rised now due to the improvement in the locking system12:27
dviroelbut I still need to dig more into this issue12:27
dviroelthe other 2 are possble improvements to the strategy itself12:27
amoralejI think the issue is related, actually we could see it as a pre-existing issue but was mitigated by the per-method shared lock12:28
amoralejbut yeah, it deserves some careful review12:29
dviroel2) destination nodes ordering and selection in simulate_strategy12:29
dviroel3) source nodes ordering and selection in simulate_strategy12:29
dviroelthe TL;DR; of those 23 are in the etherpad12:29
dviroel#link https://etherpad.opendev.org/p/watcher-workload-stabilization-improvements12:29
amoralejI will check 2 and 3 soon i hope12:29
dviroelwith some outputs from my local tests12:30
dviroelthe lock improvement show 9.5x speedup there 12:30
dviroelthe other ones are open for discussion in the end12:31
amoralejthanks for the documentation dviroel++ looks great12:31
dviroelanother thing12:31
dviroelthere is a bug in the code 12:31
dviroel#link https://bugs.launchpad.net/watcher/+bug/215225412:31
dviroelwhich we don't see it happen since all calls for map_instance are using instance objects, not uuid string12:32
dviroelbut it is possible to reproduce using uuid strings12:32
dviroel#link https://review.opendev.org/c/openstack/watcher/+/98829712:32
dviroelis a unit test that can reproduce the issue for instance12:33
dviroelnext thing is to investigate the  error in the12:34
dviroel#link https://review.opendev.org/c/openstack/watcher/+/98754012:34
dviroel"Replace global lockutils locks with per-instance RLock" since is the most important fix/improvement there12:34
dviroelthat's it12:35
dviroeli will follow up this ^ patch here and provide more updates soon12:35
dviroelif there is no other question about them, we can move on12:36
jgilaberthanks dviroel there is a lot of information in the ehterpad12:36
dviroelwe can sync again next week in this topic too12:36
jgilaberwe can move on to bug triage then12:36
dviroelack12:36
jgilaber#topic Bugs12:37
jgilaberwe have a couple from last week and some newer ones12:37
jgilaber#link https://bugs.launchpad.net/watcher/+bug/183740012:37
jgilaberthis one is old but is still marked as "New"12:37
jgilaberwe marked it as "needs-re-triage" last year12:37
dviroelneeds to see if it reproduces in newer releases12:39
dviroelthere is no info about which release was used in this test12:40
dviroelso it is incomplete, unless someone try to reproduce it12:41
dviroelno?12:41
jgilaber+1 to that, there is also no job in ci testing this datasource12:41
jgilaberany objection to marking it as incomplete?12:41
amoralejin recent job i see "CRITICAL watcher.decision_engine.datasources.grafana [None req-7fe25725-c0ee-41f8-8000-9b71131638b2 None None] GrafanaHelper authentication token not configured"12:42
amoralejwhich seems to be a different one ?12:42
jgilaberthat seems different, which job is that?12:42
jgilaberI wasn't aware of any that would enable this datasource12:42
dviroeldifferent message but could be the same source of issue12:43
amoralejhttps://zuul.opendev.org/t/openstack/build/ca7e211e7a75482ab1a78b6109924d7512:43
amoralejhttps://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ca7/openstack/ca7e211e7a75482ab1a78b6109924d75/controller/logs/screen-watcher-decision-engine.txt12:43
dviroel"May 13 10:01:39.699638 np46f41325385c4 watcher-decision-engine[101325]: CRITICAL watcher.decision_engine.datasources.grafana [None req-b2e0fb46-8fab-4c63-b700-b92b856b367c None None] GrafanaHelper authentication token not configured"12:44
amoralejactually, it's not enabled12:44
dviroelit is not good to have a CRITICAL message logged 12:44
jgilaberthat job configures prometheus as the only datasource https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_ca7/openstack/ca7e211e7a75482ab1a78b6109924d75/controller/logs/etc/watcher/watcher_conf.txt12:44
amoralejit's probably helper initialization image12:44
amoralejinitialization error, i meant12:44
dviroelsomeone has cycles to take a look whats going on?12:45
dviroelbut the LP Bug seems to be actually using grafana12:46
dviroelthe issue with a CRITICAL log from grafana, which wasn't configured as datasource 12:46
dviroelit something that shold be fixed12:46
dviroelI think that  we can file another LP for that12:47
jgilaberyes, we should it's a different problem12:47
dviroeli would keep 1837400 as incomplete12:47
dviroeland file a new one to investigaste the Critical log in the job12:47
jgilaberagreed12:48
dviroelack12:48
amoraleji can create it12:48
dviroelthanks amoralej 12:48
jgilaberI'm also looking at the tags, and we don't have any for datasources12:48
jgilaberok to create one?12:49
dviroelyeah12:49
jgilaberack done12:49
jgilaberlet's move to the next one12:49
jgilaber#link https://bugs.launchpad.net/watcher/+bug/215177612:49
dviroeldavid filed this one12:50
dviroelit is weird that strategy need to check in the model if a instance is excluded or not12:51
amoralejftr https://bugs.launchpad.net/watcher/+bug/215262312:51
dviroelbut it may have its own reason for that, which we may agree or not and plan a fix12:51
* dviroel tks amoralej 12:51
amoralejI think there is a reason for that. We may change how the model works to change that behavior but until then, i think it's a valid bug12:53
dviroelI agree that is valid12:53
amoralejsomething we may do is to fix the existing issues with current model, and think on improvements on the model and scope behavior as separated issues12:54
jgilaber+1 it's valid and high imo since it could lead to users migrating instances by mistake12:54
jgilabershort term we could add the check for "watcher_exclude" to the strategies that are missing it 12:54
dviroelthis requires more investation on each strategy I think. Maybe some of them could have their doc updated to reflect that exclude instance would not work? 12:54
amoralejyes, note that in some cases strategies may need to list all the instances even the excluded ones, and in other only the non-excluded12:55
amoraleji think that's why it was implemented in that way12:55
jgilaberthat makes sense for host_maintenance but not so much for zone migration for example12:56
dviroelfixing with a check will require more testing on each too, so maybe each strategy needs an investigation12:56
amoralejor maybe not :)  but needs careful investigation on each strategy as dviroel said12:56
jgilaberack, we've only got 4 minutes, let's decide on  the importance and revisit12:57
jgilaberor do we want to retriage next week with more time?12:57
amoralejwhat i'd like is to get more information from David too, to get the actual problematic behavior explained instead of the implementation detail12:57
dviroeli would say that is high, since in the end, the action plan could end up moving instance that user don't want to12:58
amoralej+112:58
jgilaberack, let's bring it up next week again12:58
jgilaberdviroel, ok if we move your bug to next week as well?12:58
dviroelsure, np12:58
jgilaberthanks12:58
jgilaberlast topic12:59
jgilaber#topic Stable releases12:59
jgilaberlooks like we still have a few backports open for stable/2025.* branches12:59
amoraleji reviewed some backports in stable releases12:59
jgilaberthanks amoralej 12:59
amoralejyep, it'd be good to get first the 2025.2 reviewed12:59
amoralejand merged, to make sure we don get stuff in 2025.1 which is not in .213:00
dviroel++ 13:00
amoralejalso i sent one to 2026.1 btw, the one about the debug logs for workload_balance13:00
jgilaberagreed, please review when time allows13:00
amoralejhttps://review.opendev.org/q/project:openstack/watcher+branch:stable/2026.1+status:open13:01
jgilaberanything else on this topic?13:02
jgilaberlast thing for today then13:02
jgilaber#topic Volunteers to chair next meeting13:02
jgilaberany volunteer?13:02
amoraleji can take it13:02
jgilaberthanks amoralej 13:02
dviroel++13:02
dviroelthanks amoralej 13:02
jgilaberand thanks everyone for the discussion!13:03
jgilaber#endmeeting13:03
opendevmeetMeeting ended Thu May 14 13:03:06 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:03
opendevmeetMinutes:        https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-05-14-12.01.html13:03
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-05-14-12.01.txt13:03
opendevmeetLog:            https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-05-14-12.01.log.html13:03
amoralejwrt https://review.opendev.org/c/openstack/watcher/+/981225 i understant we want that in 2026.1 as it's slurp ?13:03
dviroelthanks for chairing jgilaber++13:03
amoralejthanks jgilaber++ !13:03
jgilaberthat is a good question, I was thinking the same thing13:03
amoraleji know little about grenade jobs tbh13:03
amoralejchandankumar, ^13:04
chandankumaramoralej: skip-level-always runs from n-2 to n relase while normal grenade job runs from n-1 to n13:08
chandankumar2026.1 is a slurp release13:09
jgilaberthat seems to follow guidance from https://docs.openstack.org/project-team-guide/release-cadence-adjustment.html#details13:09
jgilaber+1 from me13:09
amoralejso, in slurp we need to run skip-level-always, right? and in non-slurp regular grenade ?13:10
jgilaberhowever the grenade jobs did not run in that patch, is that because of irrelevant-files?13:10
chandankumarhttps://opendev.org/openstack/tempest/src/branch/master/zuul.d/integrated-gate.yaml#L52113:10
sean-k-mooneyskip-level-alwasy13:10
sean-k-mooneyis intended to be run on every release13:10
chandankumarIt run on all branches13:10
sean-k-mooneybut we offically only supprot .1 -> .113:10
sean-k-mooneyand .2 -> .1 13:11
sean-k-mooneyupgragdes13:11
sean-k-mooneythe .2 -> .213:11
sean-k-mooneythat it tests on non slup release13:11
sean-k-mooneyis there to catch bugs early13:11
sean-k-mooneybut not officaly supprotd13:11
sean-k-mooneyit also useful when some downstream vendor use dto do 3 release of FFU...13:11
amoralejgot it, thanks!13:12
*** haleyb is now known as haleyb|away15:21

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