Thursday, 2025-10-09

opendevreviewJoan Gilabert proposed openstack/watcher master: Handle optional pool fields in Cinder notification  https://review.opendev.org/c/openstack/watcher/+/96166708:26
chandankumarsean-k-mooney: thank you for sharing the detailed improvement plan https://gist.github.com/SeanMooney/8746be1c29bbb78a63ef88f0104ea54f , it will help a lot!09:32
sean-k-mooneychandankumar: i also created a high level spec to cover the over all usecase and motivation https://review.opendev.org/c/openstack/watcher-specs/+/96343810:58
sean-k-mooneyhttps://gist.github.com/SeanMooney/8746be1c29bbb78a63ef88f0104ea54f is the high level plane but the detailed low level impeleation plan i created is https://gist.github.com/SeanMooney/f56c7fd6f55ac48958a5c549e1701b6c10:59
dviroelhi all o/, watcher meeting will start in 5 11:55
dviroel#startmeeting watcher12:01
opendevmeetMeeting started Thu Oct  9 12:01:02 2025 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
dviroelhi all, lets see who is around today12:01
jgilaber_o/12:01
*** jgilaber_ is now known as jgilaber12:01
chandankumaro/12:01
amoralejo/12:01
dviroelcourtesy ping: sean-k-mooney morenod rlandy12:02
dviroellet's start with today's meeting agenda12:02
dviroel#link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L27 (Meeting agenda)12:02
dviroelfeel free to add your own topics to the agenda12:02
sean-k-mooneyo/12:02
dviroelthere are topics to place your changes that requires attention from reviewers12:03
dviroellets start with 12:03
dviroel#topic Announcements12:03
dviroelPTG Schedule12:03
dviroel#link https://ptg.opendev.org/ptg.html12:03
dviroelbased on our decisions from last meeting12:04
dviroeli booked Tue, Wed and Thu for watcher12:04
dviroel13 - 15 UTC12:04
dviroelone week before, I plan to organise our topics12:04
dviroelif you have any topic that you want to discuss, please add it to our PTG etherpad12:05
dviroel#link https://etherpad.opendev.org/p/watcher-2026.1-ptg12:05
sean-k-mooney13 - 15 UTC being an incluse range so we have 3 hours each day12:05
dviroelcorrect12:05
sean-k-mooneythere are sever topic i think can be merged togther into sessions12:07
sean-k-mooneyi.e. many of the curernt topic have similar theme so we can group the related topics toghther 12:08
dviroelagreed12:08
amoralej+112:08
dviroelI plan to group similar theme 12:08
dviroeland also merge some of the topics that I plan to bring12:09
sean-k-mooneywe should invite the telemetry team to https://etherpad.opendev.org/p/watcher-2026.1-ptg#L35 : Future of datasouces backends and untested integrations12:09
amoralejI added one about "Improving testing coverage for strategies", that should be in the CI testing/coverage block i think12:09
sean-k-mooneythey are nto required but they may have input into the Aetos vs promethose topic12:09
dviroelack12:09
sean-k-mooneythere are at least 3 diffent ci/testing topics12:10
sean-k-mooneyand i wote 2 specs/impelation plans with ai over the last few days to help with that as well12:10
dviroelso yeah, for now, we can just drop topics there in the etherpad12:11
amoralejI just moved the one i created12:11
dviroelwe can then group them and find a slot for it12:11
amoralejthanks Sean for adding the link to your spec there12:11
chandankumarDo we want to merge watcher-dashboard ci topic under other CI topics?12:12
jgilaberI think the dashboard case might be different enough to merit being a separate topic12:12
jgilaberbecause of the stack used (django, html, etc)12:12
dviroelyeah, but we can have both in a sequence12:13
chandankumar+1 to keep in sequence12:13
jgilaber+112:13
amoralejlgtm12:13
dviroelack, anything else related to the vPTG?12:14
dviroelany other announcement?12:15
dviroel#topic Moving decision-engine monitoring to the decision-engine service12:15
dviroelhey amoralej, seems that this one is yours12:15
amoralejyes12:15
dviroel#link https://review.opendev.org/q/topic:%22bug-2126767%2212:15
amoralej#link https://review.opendev.org/q/topic:%22bug-2126767%2212:15
dviroel:) 12:15
amoralejdamn :)12:16
amoralejso, i sent a couple of patches related to moving the decision engine monitoring to the decision-engine service12:16
amoralejI have several questions12:16
amoralejI moved it from the watcher-api to the decision-engine inconditionally12:17
amoraleji mean, no deprecation, no config parameter, etc...12:17
amoraleji think this is transparent for the users12:17
amoralejand even to the admin12:17
amoralejso i don't see the need to do something more complex than adding a release note12:17
amoralejwdyt ?12:17
dviroelin the end you are really fixing a bug12:18
amoralejan user running watcher-api as a wsgi will get a bug fixed when updates, an user running eventlet based watcher-api will keep same functionality but in a different service12:19
jgilaberiiuc the monitor service is currently not running by default right?12:19
amoralejyes, that's also my opinion12:19
amoralejit is running when running watcher-api as a standalone service only12:19
amoralejnot as wsgi server12:19
jgilaberwe don't have any env like that in ci right?12:20
dviroelthe standalone? i don't think so12:20
sean-k-mooneysorry had to leave for a phone call12:21
sean-k-mooneyback12:21
amoralejnp12:21
amoralejright, devstack runs it with uwsgi iiuc12:21
* dviroel look at ci failure12:21
* dviroel not related12:22
jgilaberit doesn't look like we lose any functionality to me12:22
sean-k-mooneywell the watcher-api evently proicess is due to be delete perhaps even this cycle althoug definlty in 2026.212:23
sean-k-mooneyso i think this is not really a regression. however we coudl allow it to work form either location12:23
amoralejyeah, but then we'd have to add parameters, etc... dunno if it's worthy tbh12:23
amoralejthat was my doubt12:24
sean-k-mooneyack12:24
amoralejif we would allow to run in either or both, we'd need to include the api also in the leader election process etc..12:24
sean-k-mooneywe may or may not want to have a config opiont12:25
dviroelto keep the current behavior, you would need to add a config to enable/disable the functionality in dec-eng, with the later disabled by default12:25
sean-k-mooney*option12:25
sean-k-mooneyright so we likely would want to have the config option in either case12:25
amoralejyes, that'd be like the way to keep current behavior by default and adding the new one12:25
sean-k-mooneywe can have 1 that is shared between both services12:26
amoralejbut watcher-api is not registeres as a service in watcher12:26
amoraleji mean, for the leader election12:26
sean-k-mooneyah that is a good point12:26
sean-k-mooneythe implemtin woudl not be identical althogu i guess it does not have to be12:26
sean-k-mooneywe could copy rather then move the currnt code and deprecate teh nova-api version12:27
amoralejthe question is if it's worthy12:27
sean-k-mooneyagain im not sure its worht the effort either12:27
amoralejyes, that'd be an option sean-k-mooney, but again if an user runs it in both sides, may have unexpected12:27
sean-k-mooneyso i think we can just deprecate teh nova-api version and docuemtn it and remove it12:27
amoralejactually, i realized i added it as a fix in releasenote, and may be also deprecated12:28
sean-k-mooneywell this is also not a bug12:28
sean-k-mooneyits a feature so it shoud have a bluepritn at a minium12:28
amoralejwe discussed in lat minute it could be a bug12:28
amoralejlast meeting, i meant12:29
amoralejgiven that it's regression on moving from eventlet to wsgi12:29
sean-k-mooneyit coudl be a whislise bug to minize paper work but its not somethign we woudl consider backporting upstream12:29
amoralejah, ok, i wasn't thinking in backporting at this point tbh12:29
sean-k-mooneyi guess we can move forward with thsi and dicuss this more in the implementaion12:30
dviroelyeah, doesn't seems safe to backport12:30
amoralejlet's keep the discussion about backporting as a separate one12:30
amoralejok12:30
amoralejso next question is, i added the leader election in spearate review, dunnow if you prefer me to squash?12:31
amoraleji found easier to review 1. move 2. add leader election12:31
amoralejbut can squash if you prefer12:32
jgilaber+1 to have two patches, they are easier to review and smaller12:32
sean-k-mooneyi think either is fien it woueld be more correct to squash but we can just have a single release note for both patches and update it in the second one to note it is now safe to enable if you have more then one desion engine12:32
amoraleji like that12:33
dviroelok to split if the first one works properly without the second one12:33
sean-k-mooneythe first patch shoudl have a cofnig option to opt into it and say this is currently only supproted on one desion engine at a time and you remove that limitation in the second patch12:33
amoralejthat's the point, the first one only may be problematic if running multiple dec-eng12:33
amoralejthen i will squash :) 12:34
sean-k-mooneyok well the other thing is did you look at why watcher-prometheus-integration-threading failed 12:34
sean-k-mooneyah it was just 1 test12:34
dviroelyes, just checked12:34
amoraleji think it's unrelated, it's a tempest test failed12:34
sean-k-mooneyso likely not relatd12:35
amoralejbut yeah, i will check why that on e failed12:35
dviroelwith the recent refactoring on tempest12:35
jgilaberthat job seems a bit flaky, I've seen it fail in a different patch https://zuul.opendev.org/t/openstack/builds?job_name=watcher-prometheus-integration-threading&project=openstack/watcher12:35
sean-k-mooneywe should look at enabling a second desion engine in the job also to test this properly12:35
dviroeli may see some test that sometimes don't generate a Recommended action plan, and will fail12:35
amoralejthat's another question sean-k-mooney, lemme go to that at the end :)12:35
dviroelso we would need to improve these tests12:36
dviroelto avoid failures like that12:36
amoralejanother question i have, current code only takes care of audit migrations when there is a change in the state of a decision-engine. It saves some api calls and processing but may have corner cases12:36
sean-k-mooneydviroel: ya i have notice at least one test failing semi often because of not actions in the plan12:36
amoraleji.e. decision-engine-0 dies while decision-engine-1 is not running. Then decision-engine-1 is started12:36
sean-k-mooneywell the way this shoudl work is 1 the perodic shoudl run on agent start and 2 it shoudl set that it is the leader 12:37
amoralejif a decision-engine is detected as failed at start, then it will not look for assigned audits to it12:37
sean-k-mooneyso decision-engine-1 on start shoudl rebalance12:37
amoralejnot with current implementation12:37
sean-k-mooneyright but that need to be fixed in the first patch12:38
amoralejcurrent = the one in watcher-api12:38
amoralejack, I will, i was unsure that was a bug or a feature :)12:38
sean-k-mooneywell i was leaning betwen blueprint and specless blueprint so im definlty in hte feature camp for this over all12:38
dviroelso, maybe another reason to consider a new implementation in dec-eng, and deprecate the api version one12:38
sean-k-mooneyim ok with it as a bug because of the eventlet removal btu if we are going to supprot this protperly in the descion engin12:39
sean-k-mooneyi dont wnat to claim supprot for this until the know issuee are adressed12:39
sean-k-mooneythat does nto mean it all has to happen in one patch12:40
sean-k-mooneybut it does mean that the first patch in its current form should not have Closes-Bug: #212676712:40
sean-k-mooneyit should have partial-bug 12:40
amoraleji was thinking in squashing12:40
amoralejwould it be fine if i squash both patches + fix the logic in the new implementation for the issue i mentioned?12:41
dviroelhum12:42
amoralejfeel free to propose what'd be better12:42
dviroelto  use the same bug, would be good to add more details to the LP12:43
amoralejor i can treat the second issue as a separate bug12:43
sean-k-mooneyso you coudl fix the issue of not handling the down service in the api version first12:44
sean-k-mooneybefore the prot/refactor that your are doing 12:44
amoralejah, that'd be another option... right12:44
dviroelsplit the issues in two LP seems better imho12:46
amoralejreport it as a new bug (bug2), 1st review: fix bug2 in watcher-api, 2nd review: move + leader election12:46
sean-k-mooneythat sound reasonable to me +112:46
dviroelok, amoralej anything else in this topic? I think that we can get more feedbacks in the reviews12:47
amoralejwrt testing12:47
dviroelsure12:47
amoralejdunno if today or in ptg12:47
amoralejhow/if we test high availability upstream12:47
amoralejbut, we are short on time, we can discuss that in next meeting or ptg, no problem12:48
dviroeli think that we can discuss at the ptg? it may require more time to discuss12:48
amoralejyeah +112:48
amoraleji'm done then, thanks for your feedback!12:48
dviroelthanks amoralej@12:48
dviroels/@/!12:48
dviroelwe have 10m, so lets quickly cover some open reviews12:49
dviroel#topic Reviews12:49
dviroeli will cover mine first12:49
dviroel960381: Fail if action plan cannot be execute | https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/96038112:49
dviroelthis is kind of one of the things that i wanted to fix12:50
dviroeltest were just retuning sucess if no action plan is generated12:50
sean-k-mooneyamoralej: we do not need to test the fail over but i do wnat to see 2 things, 1 we shoudl have 2 dession engine enabled in a job and 2 i want to see a debug log showing that one was elected the leader and the other was not. 12:50
dviroelwhich doesn't actually properly test the outcome of a strategy12:50
sean-k-mooney"Fail if action plan cannot be execute"12:50
sean-k-mooneyya that is an important fix IMO12:51
dviroelso we might see some test that sometimes don't generate an action plan, to fail in CI12:51
sean-k-mooneyit may uncover other flaky tests but that a good thing12:51
dviroellike the one in amoralej patches above12:51
sean-k-mooneyya12:52
dviroelwhich is likely the case12:52
jgilaber+112:52
dviroeland then we can work on improving the test, to keep ci more stable12:52
dviroelok, next one12:52
sean-k-mooneyi just reviewd it now and approved it FYI12:52
dviroelone from eventlet removal that was pending at my side12:52
dviroelsean-k-mooney: tks12:53
dviroel960881: Add ThreadPool statistics debug log | https://review.opendev.org/c/openstack/watcher/+/96088112:53
dviroelthis is a similar approach from nova code, that print threadpool statistics12:53
dviroelwhich would be helpfull for debug12:54
sean-k-mooneyya i agree that it should eb off by default and have its own config option12:54
dviroelsince watcher has couple of thread pools around12:54
sean-k-mooneyi think print_thread_pool_stats is ok12:55
sean-k-mooneyand i see you enabled it in the zuul jobs12:55
sean-k-mooneyill review teh patch fully and the job output later but i think this looks good overall12:55
dviroelack, thanks12:55
dviroelthanks jgilaber for the review ther too12:55
dviroelnext one12:55
dviroel955472: Add Continuous audit dummy strategy scenario test | https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/95547212:56
chandankumarIt adds coverage for continuous audit using dummy strategies in scenario test, validating all state of Audit, Updating start/end time/interval with sec and crontab.12:56
chandankumarIt will make sure everything is working for continous audit.12:56
dviroelchandankumar: ack, i already start reviewing it12:56
chandankumardviroel: thank you!12:57
dviroelwe are moving from nothing to many test for continuous audits12:57
dviroel:)12:57
dviroelthanks for proposing12:57
dviroelnext one12:57
dviroel958644: Add test for volume migrate with zone migration | https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/95864412:57
jgilaberthis adds a test for zone migration where it migrates volumes12:58
dviroeljgilaber: is proposing some new volume migrate tests12:58
dviroel++12:58
jgilaberwe already merged the one with retype12:58
dviroelack, S change, I can add to my list too12:58
dviroelthanks12:58
jgilaberthis test assumes that there are at least two cinder pools configured with the same volume_backend_name12:59
jgilaberotherwise it's skipped12:59
dviroelack, I see that you rebased based on the refactoring ++12:59
jgilaberI'm looking to add a similar test with multiple backends12:59
dviroelack13:00
dviroel960265: Handle missing fields building storage model XML | https://review.opendev.org/c/openstack/watcher/+/96026513:00
dviroelthis is a fix for https://bugs.launchpad.net/watcher/+bug/212114713:00
jgilaberthis and the other two patches are all related to the storage model13:00
dviroel961667: Handle optional pool fields in Cinder notification | https://review.opendev.org/c/openstack/watcher/+/96166713:01
jgilaberit logs some exceptions that are not really errors and can be confusing for the user13:01
dviroel958781: Add some debug logs to storage model | https://review.opendev.org/c/openstack/watcher/+/95878113:01
jgilaberlast one adds logs to clarify, the other two prevents erros over optional fields13:01
dviroelack, so it would be good to review all them together13:02
sean-k-mooneyjgilaber: ok so you moved it form log.excption which is actully at error level to log.debug 13:02
jgilaberI would say they are not super urgent, mainly UX improvements13:02
dviroelack13:02
sean-k-mooneyim not sure https://review.opendev.org/c/openstack/watcher/+/960265 is the write way to fix that but i have not looked deeply enought to provdie a difetn suggestion13:03
sean-k-mooneyto me that is just hiding the issue rather then fixing it13:03
jgilabersean-k-mooney, yes, since it was not really an error ( the storage model is building correctly)13:03
dviroelyeah, I can't provide a feedback now, I will need to spend some time on it, even being XS change :)13:03
jgilaberI think the right fix is to remove those optional fields13:04
jgilaberbut this is a small improvement for the logs13:04
dviroelack, we are over time, going to close the meeting, but feel free to continue the discussion in the channel13:05
dviroelthanks jgilaber for volunteering to chair next meeting13:05
sean-k-mooneyjgilaber: i fell like we shoudl do the real fix rather then the logging change13:05
dviroellet's wrap up13:05
dviroelthank you all for participating13:05
dviroel#endmeeting13:05
opendevmeetMeeting ended Thu Oct  9 13:05:57 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:05
opendevmeetMinutes:        https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-10-09-12.01.html13:05
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-10-09-12.01.txt13:05
opendevmeetLog:            https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-10-09-12.01.log.html13:05
chandankumardviroel: ++ thank you for running the meeting!13:06
sean-k-mooneyhttps://review.opendev.org/c/openstack/watcher/+/958781 seams harmless enough to me so im +2 on it13:06
amoralejthank you dviroel++ !13:07
jgilabersean-k-mooney, that's fair, but I would probably have to tackle it in the future, I'm not sure how complex that might turn out to be13:09
jgilaberespecially considering this is low severity bug13:09
*** haleyb_ is now known as haleyb13:28
opendevreviewMerged openstack/watcher-tempest-plugin master: Fail if action plan cannot be execute  https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/96038113:29
opendevreviewJoan Gilabert proposed openstack/watcher-tempest-plugin master: Test zone migration volume and compute migrations  https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/96270213:32
opendevreviewJoan Gilabert proposed openstack/watcher-tempest-plugin master: Add extra checks to zone migration retype test  https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/96355913:32
opendevreviewchandan kumar proposed openstack/watcher-tempest-plugin master: Added tempest API tests for continous audit  https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/95600414:17
opendevreviewchandan kumar proposed openstack/watcher-tempest-plugin master: Added tempest API tests for continous audit  https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/95600414:22
opendevreviewMerged openstack/watcher master: Add some debug logs to storage model  https://review.opendev.org/c/openstack/watcher/+/95878114:23
opendevreviewDouglas Viroel proposed openstack/watcher-tempest-plugin master: Add tests for extended compute datamodel  https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/95611619:35
opendevreviewDouglas Viroel proposed openstack/watcher master: Enable data_model tests in jobs and update tempest configs  https://review.opendev.org/c/openstack/watcher/+/95867819:36
*** haleyb is now known as haleyb|out23:22

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