Thursday, 2026-07-02

opendevreviewchandan kumar proposed openstack/watcher-dashboard master: Add Playwright-based E2E testing framework  https://review.opendev.org/c/openstack/watcher-dashboard/+/97035304:43
opendevreviewchandan kumar proposed openstack/watcher-dashboard master: Add Playwright-based E2E testing framework  https://review.opendev.org/c/openstack/watcher-dashboard/+/97035305:14
opendevreviewAlfredo Moralejo proposed openstack/watcher-specs master: Add spec for Action Plan Transformers Framework  https://review.opendev.org/c/openstack/watcher-specs/+/99460707:57
opendevreviewchandan kumar proposed openstack/watcher-dashboard master: Add Playwright integration test for skip action workflow  https://review.opendev.org/c/openstack/watcher-dashboard/+/97659408:55
chandankumaramoralej: sean-k-mooney: Hello, On playwright patch, by using tox venv I am able to install playwright and then use venv playwright binary to install deps and broweser binaries,09:12
chandankumarFeel free to take a another look on https://review.opendev.org/c/openstack/watcher-dashboard/+/970353/79 thank you!09:12
amoralejsure, reviewing now09:12
chandankumarty!09:13
amoralejchandankumar, in the doc doc/source/contributor/playwright-testing.rst , shouldn't be a previous step to install the system deps with sudo before installing the browsers? sudo python -m playwright install-deps 09:31
opendevreviewDavid proposed openstack/watcher master: Add three-node setup for non-real-data jobs  https://review.opendev.org/c/openstack/watcher/+/99579710:21
opendevreviewDavid proposed openstack/watcher master: [DNM] Add three-node setup for non-real-data jobs  https://review.opendev.org/c/openstack/watcher/+/99579710:22
opendevreviewAlfredo Moralejo proposed openstack/watcher-specs master: Add spec for Action Plan Transformers Framework  https://review.opendev.org/c/openstack/watcher-specs/+/99460710:28
opendevreviewDavid proposed openstack/watcher master: Add three-node setup and enable scope tests  https://review.opendev.org/c/openstack/watcher/+/99579710:33
chandankumaramoralej: yes, correct, I fixed that part10:36
opendevreviewchandan kumar proposed openstack/watcher-dashboard master: Add Playwright-based E2E testing framework  https://review.opendev.org/c/openstack/watcher-dashboard/+/97035310:36
opendevreviewDavid proposed openstack/watcher master: [DNM] Add three-node setup and enable scope tests  https://review.opendev.org/c/openstack/watcher/+/99579710:37
opendevreviewDavid proposed openstack/watcher-tempest-plugin master: Add test suite for audit scope  https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/99579910:39
opendevreviewDavid proposed openstack/watcher-tempest-plugin master: [DNM] Add test suite for audit scope  https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/99579910:40
opendevreviewAlfredo Moralejo proposed openstack/watcher-specs master: Add spec for Action Plan Transformers Framework  https://review.opendev.org/c/openstack/watcher-specs/+/99460711:01
sean-k-mooneychandankumar: amoralej  im inlcidne to say perferct is the enamy of good enough. the playwright patch is "good enough" to merge now and we can likely clean up the other nits seperatly11:11
amoralejwfm11:13
chandankumarsounds good.11:17
sean-k-mooneywe have the irc meeting today right?11:18
sean-k-mooneyin an hour? or two hours?11:18
sean-k-mooneyif doug is happy wiht it we can merg it during the meeting11:18
chandankumar+111:20
sean-k-mooneyi think the premetion spec is also close11:32
sean-k-mooneythere are a few things to refine 11:32
sean-k-mooneyjgilaber: you raissed some valid point that likely shoudl be adressed11:32
sean-k-mooneyi wonder if we realsiticlly can adress all of it by the end of the day11:33
sean-k-mooneytoday being the spec freeze deadlien we shoudl disscusin the meetingf if we are ok with granting ti an expction till next week or not.11:33
sean-k-mooneyi would not want to extended the deadline beyond next weeks irc meeging11:34
sean-k-mooney*meeting11:34
dviroelo/11:57
dviroelhi all, a reminder that starting today, we have a new meeting time11:58
dviroelhttps://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/CLQ7AEJO32LIOQIX5J4YTXVMHQECZOVZ/11:58
dviroelthe meeting will start at 1:00 PM 11:59
dviroelfeel free to add your topics to the agenda11:59
dviroelhttps://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L3111:59
sean-k-mooneydviroel: the only itmes i had was playwright and the permetion spec12:00
sean-k-mooneysee the converstaion above12:00
dviroelack, i was reading back12:00
dviroelgiong to revisit both now12:01
winiciusallan[m]o/12:01
winiciusallan[m]i've just started my day. i'll check the comments in the preemptible spec in a bit12:02
sean-k-mooneyno worreies. just a procedural matter today is spec freeze so the topic i have for the meeting is do we enfoce that and derfer your spec to nextg cycle or grant a limited excpetion to say next week to allwo you to fix the remaiing small peices12:03
winiciusallan[m]i'm okay with guys prefer to move this spec for the next cycle as the deadline is today and we have a few things to refine12:14
winiciusallan[m]i had a time requirement on my end and I would need to merge it on this cycle, but I don't have it anymore and I'm okay in following what works better12:15
dviroelwiniciusallan[m]: we can discuss in the meeting, no worries12:20
opendevreviewAlfredo Moralejo proposed openstack/watcher-specs master: Add spec for Action Plan Transformers Framework  https://review.opendev.org/c/openstack/watcher-specs/+/99460712:33
dviroelsean-k-mooney: amoralej: there is already enough +2 in playwright patch, I think that we can proceed to work in improvements as follow up if needed...12:54
dviroeli also +212:55
dviroelw+1 already12:55
dviroelchandankumar: thanks for the hard work there 12:55
dviroelfolks, watcher meeting will start in 3 minutes - agenda https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L3112:57
dviroel#startmeeting watcher13:00
opendevmeetMeeting started Thu Jul  2 13:00:08 2026 UTC and is due to finish in 60 minutes.  The chair is dviroel. Information about MeetBot at http://wiki.debian.org/MeetBot.13:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:00
opendevmeetThe meeting name has been set to 'watcher'13:00
dviroelhello everyone o/   -  who is around today13:00
jgilabero/13:01
dviroelcourtesy ping: amoralej sean-k-mooney chandankumar morenod rlandy13:02
morenodo/13:02
amoralejo/13:02
dviroellets strat while folks are joining..13:03
dviroellet's start with today's meeting agenda13:03
rlandyo/13:03
dviroel#link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L31 (Meeting agenda)13:03
dviroelas usual, feel free to add your own topics to the agenda13:03
dviroelstarting with13:03
dviroel#topic Announcements13:03
sean-k-mooneyo/13:04
dviroelso yeah, we reach hibiscus milestone 213:04
dviroel#link https://releases.openstack.org/hibiscus/schedule.html13:04
dviroeland with that we reach our deadline for new specs13:05
dviroelwe were discussing them past week13:05
dviroelwe have a few of them that are open13:05
dviroel#link https://review.opendev.org/q/project:openstack/watcher-specs+is:open13:05
dviroeli think that both Add spec for migration eligibility filters feature and13:06
dviroelAdd spec for Action Plan Transformers Framework13:06
dviroelwill need to be moved to 2027.1 as we didn't had enough time to discuss and refine13:07
dviroelthe first one I'm proposing and i intend to move it to 2027.1 folder13:07
winiciusallan[m]o/13:07
sean-k-mooneyim ok with continuting to review it for 2027.1 but ya with the cyborg spec i did not have time to look at it13:07
dviroelamoralej: any objection?13:07
dviroelwe can still discuss the specs yeah, with more time13:08
amoralejwould it work if we give one more week to review the transformers?13:08
dviroeldo you think that is feasible to implement it in 2026.2? 13:08
amoralejanyway, iiuc i can send patches for implementation even if it's not approved yet13:09
amoralejlemme recheck dates13:09
sean-k-mooneyi would perfer to instead comple say the funciotnal testing owrk13:09
sean-k-mooneyif you have time this cycle then start this work with the other work in flight13:10
amoraleji sent all the patches for functional as i'm aware13:10
dviroeli am reviewing the functional test framework yeah13:10
amoralejmore tests may be added but the framework is complete13:10
sean-k-mooneyack i have not been following that sorry13:10
dviroelwe can get back to them in the reviews topic, soon13:11
jgilaberI haven't reviewed that either but would the functional framework allow us testing the ironic helper?13:11
sean-k-mooneywhen you say compelt does that include regression tsts and non gabbit tests13:11
amoralejone thing i can do is to still have patches for the transformers even if it's not approved and get it back on it early after 2026.213:11
dviroeli didn't had time to check the Action Plan Transformers framework spec yet, not sure how complex it would be13:12
sean-k-mooneyok looking at i tthe asse seams to be yes13:12
amoralejsean-k-mooney, i'd say so13:12
chandankumaro/13:12
sean-k-mooneyjgilaber: it could 13:12
amoralejnp dviroel legt's prioritize the other work13:12
dviroelit is not only about imlpementation but also about review bandwidth in the end13:13
jgilaber+1 that is the worry13:13
amoralejjgilaber, i didn't add ironic service fixtures, but may be added following similar approach if that's good13:13
sean-k-mooneymy perfernce woudl be to defer ther tramsformes work and destination filterign to next cycle13:13
sean-k-mooneybut to start in the implemiton and contionue the review13:14
amoralejok13:14
jgilaberthanks, I'll try to make some time to review them and might add that later in the cycle13:14
sean-k-mooneybaiscly aim to complete them for milestoen 113:14
dviroelyeah, I do want to have destination filter proposal merged earlier in the next cycle too...13:15
dviroelwe can try that13:15
amoralejalso there are some bugs, that i may dedicate some time to13:15
dviroelyeah13:15
dviroelor any other spec less improvement..13:15
dviroelack, so the last spec in the list is13:15
amoralejyep, no problem, let's do that13:15
dviroel#link https://review.opendev.org/c/openstack/watcher-specs/+/98717113:15
sean-k-mooneywell blueprint freeze is today as well13:15
sean-k-mooneyso bugs or docs changes 13:16
sean-k-mooneyci that sort of thing13:16
dviroelthere is a lot in LP to be covered yes13:16
dviroelwrt to Add spec for Preemptible Instances feature13:17
dviroelwhich is feasible to get into 2026.2 13:17
dviroelwiniciusallan[m]: is updating the spec periodically13:17
winiciusallan[m]i think we are towards an agreed solution 13:18
dviroelbut there are still some points that we need to close before merging it13:18
winiciusallan[m]there are some implementation details that we can discuss/refine after the approval13:18
winiciusallan[m]yeah, agree13:18
dviroelwe need to at least  define the prioritization options and the efficacy indicators13:19
dviroeland it seems that reviewers agree that we don't need to do all in the first implementation13:19
dviroelplease correct me if i'm wrong13:19
dviroelwiniciusallan[m]: note that, according with the release schedule, code need to be approved and merge at the end of august13:20
dviroelwhich means that implementation, test and docs need to be proposed eralier13:20
winiciusallan[m]ack dviroel 13:20
sean-k-mooneyright, to that point i think defering the utilstiaon based aspect woudl limit scope a lot13:20
dviroelso reviewers have time to review them13:20
sean-k-mooneyand it somethign we coudl add incrementally next cycle13:20
dviroelack, same thing for multiple efficacy indicators13:21
dviroelnote that this also reduces the amount of code to be reviewed later13:21
dviroelwiniciusallan[m]: it would depend if it fits your minimal requirement 13:21
dviroelamoralej: jgilaber - any thoughts on the spec?13:22
winiciusallan[m]the spec state in a feature is good for me and i think it is feasible to the end of august13:22
winiciusallan[m]s/in a feature sense13:22
dviroelin order to get it merge, we would likely need to extend the deadline to monday I think13:22
amoralejI think it's close to be merged, I think updates covered most comments. As you said we should agree on the efficacy indicators13:23
amoralejlet's extend up to next meeting13:24
dviroelwiniciusallan[m]: once we add input_parameters and efficacy indicators, it is harder to deprecated, other than add new ones in the future13:24
jgilaberI think it's reasonable to have an extension for this spec13:24
amoralej(which i will be on pto btw)13:24
jgilaberwhat is open are not major changes I think13:24
sean-k-mooneydviroel: right once added they are basiclly supproted for ever13:24
dviroelwe are already in July, so it is expected that winiciusallan[m] already start implementing it13:24
sean-k-mooneydviroel: removing them would be possibel but we need to think carfuly how to do that13:24
dviroelyeah, that why we are focusing on that part of the spec, winiciusallan[m] 13:25
sean-k-mooneywiniciusallan[m]: do you think you can reine the spec with the remaining itmes by monday and we will review it and make the final decison next week?13:25
winiciusallan[m]yes!13:26
sean-k-mooneyany objections to that plan?13:26
sean-k-mooneyif not we can likely move on13:26
dviroelthe sooner the better13:27
winiciusallan[m]I will address comments today and you guys can see when have time today/tomorrow13:27
winiciusallan[m]or even next week13:27
sean-k-mooneyif its updated today ill review same tomorrow13:27
jgilabersounds good to me13:27
dviroelok, no objections 13:28
dviroel#agreed extend "Add spec for Preemptible Instances feature" spec deadline to next week13:28
dviroelwiniciusallan[m]: thanks, we should agree in the details soon I think13:28
dviroelwe can continue discussing them in the spec13:28
dviroelor here in the channel at any time13:28
dviroelnext topic then13:28
winiciusallan[m]alright. thanks for extending and keep reviewing13:28
dviroeloh, still in m2 topic13:29
dviroelreleases13:29
dviroeljgilaber: we can propose some stable releases if not yet proposed13:29
dviroelwe recently merged some bugfixes in 2025.2 right?13:29
jgilaberyes, I meant to look at the git history to check if they are tipically proposed automatically13:30
dviroelwe still need to focus on 2025.1 patches13:30
jgilaberif not I'll do it tomorrow13:30
jgilaberwe have merged patches in all but 2025.1 I think13:30
dviroelbut at least 2025.2 has some important fixes to have13:30
dviroeloh good then13:30
dviroelthanks jgilaber - i can sync with you afterwards then13:31
dviroelnext announcement13:31
dviroelquick one13:31
dviroel#topic OpenStack "I" Release Naming Pool13:31
dviroelin case you missed this announce in the openstack ml13:31
dviroel#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/NL3364WME3LMUIJA5NXXJOXOAGP6SDSB/13:31
dviroelyou can vote and help to select next release name13:32
dviroelok..13:32
dviroelany other announcement?13:32
opendevreviewMerged openstack/watcher-dashboard master: Add Playwright-based E2E testing framework  https://review.opendev.org/c/openstack/watcher-dashboard/+/97035313:32
dviroel^ yey13:33
dviroel#topic Reviews13:33
dviroelthis is something important to discuss today13:33
dviroelwe had some  patches that require reviewers attention13:33
dviroeland it is expected that more will be proposed in the following weeks13:33
dviroeli would like to see your opinion around how to better track them13:34
dviroelthe proposal that I have is to keep the status etherpad updated13:34
dviroel#link https://etherpad.opendev.org/p/watcher-2026.2-status13:34
dviroelthere we have our list of active blueprints, features and bugfixes13:35
sean-k-mooney that defintly one option13:35
sean-k-mooneythat is useful at the end fo the cycle when creating the release prelude ectra13:35
sean-k-mooneythe other is to add a review priroity lable to our projects13:36
sean-k-mooneyhow that woudl work is when a core does a reivew if they think its close to merge they woudl set review pirioty +2 (we woudl also use that for gate blocking issues of cves)13:37
sean-k-mooneyif anyoen thing the patch is now ready for review they can set RP+113:37
sean-k-mooneythe two are not mutally exclsive13:38
dviroeli think that both can work together yes13:38
jgilaberis that something that we need to configure in gerrit?13:38
dviroelI do like that in the etherpad we can organize per feature13:38
sean-k-mooneyyes via the project config repo13:38
sean-k-mooneydviroel: yes i like both for diffent reasons13:39
amoralejyep, i think we can use both13:39
sean-k-mooneyhaving it in gerrirt with a label means i can trivially seach by it13:39
dviroelsince not all patches sometimes are organized per topic13:39
sean-k-mooneyand have a dashboard for reviews13:39
dviroeli think that we can also try the gerrit label13:39
sean-k-mooneyhaving it itn etherpad lest use organsise it more cleanly13:39
sean-k-mooneyya there is oen other option we coudl consdier13:40
amoralejbut not having RP+1 implies is not ready for review?13:40
sean-k-mooneyamoralej: no that just nural13:40
sean-k-mooneyit might be but the person is not activlly askign for prirotisation13:40
sean-k-mooneythe idea with +1 is to allow highigihg patch that have been up for a while with no feedback or where the autor feels like its ready but a core has not weighed in13:41
sean-k-mooneyamoralej: so it would be perferct for your fucntional testing patchs13:41
sean-k-mooneyonce we started lookign at them we might upgrade it to +213:42
dviroelack, I can check how to enable this for watcher projects, if you folks agree13:42
amoralej+113:43
sean-k-mooneyif we do this can i ask we keep it simpelr then nova and not over promise anything in the lable13:43
jgilaber+1 for me too13:43
sean-k-mooneydviroel: ill find the patches i sued to configure it in nova13:43
dviroelthanks sean-k-mooney 13:43
dviroel#agreed enabling RP in watcher project to help on priotize patches that are good to merge and need attention from core reviewers13:44
sean-k-mooney#link https://review.opendev.org/c/openstack/project-config/+/78752313:44
sean-k-mooney#link https://review.opendev.org/c/openstack/project-config/+/83759513:44
dviroelnice13:45
sean-k-mooneyi dont like the "promise" nameing there13:45
sean-k-mooneybut we can figure that out in the review13:45
dviroelack, thanks, I can check that after the meeting13:46
dviroelanyone want to bring any other review to attention here?13:46
dviroelWe have a list of patches  in the review etherpad13:47
dviroelwe were talking about the functional test infra before13:47
dviroel#link https://review.opendev.org/q/topic:%22blueprint-functional-test-infrastructure%2213:47
dviroeli am reviewing the emulators part13:48
dviroeland I plan to try them in my env before adding my votes too13:48
sean-k-mooneyyep i will continue reviewing that today i have one request in the first patch13:48
sean-k-mooneybasiclly fixtures -> local_fixutres or tests/common/fixtures13:48
dviroelack13:49
amoralejthanks for your reviews, i'll check comments13:49
sean-k-mooneytldr if we call that module fixutre and you configure an ide to find tests under watcher/tests it breaks13:49
dviroelinteresting point, i think that amoralej can check that13:49
sean-k-mooneythe work around is to confiure the ide to be able to run only the unit test or funcitonal tests at a time13:49
dviroelso, in the end, I think that functional tests may save us lot of additional test that we plan to have in watcher-tempest13:50
sean-k-mooneyits easeer ot fix now then later hence the -113:50
sean-k-mooneyyes13:50
dviroelwhich are are now taking long to finish13:50
amoralejok, yep, that seems easy to fix13:50
sean-k-mooneyor rather we can still have soem of those tests13:50
dviroelso, as sooner we get the functional infra, the better13:51
dviroelsince we should have new patches proposal together with features and bugfixes13:51
amoraleji've been locally using those tests to test other patches, i.e. the openstacksdk ones13:51
sean-k-mooneybut the funciotnl test will be a lot cheaper to implemnt edgcases and failure/regressions cases13:51
dviroelwhich would increase the amount of tests and the time to complete the ci jobs13:51
amoralejand while reviewing the default_parameters one, also may be easily used to validate many cases fast13:52
dviroelwe would still need end-to-end tests for features13:52
sean-k-mooneyactully so that an interstin gpoint. for nova at least we hae a seperate tox env for the fucntional test to keep the job time shorter13:52
dviroelbut maybe not all scenarios need to be tested with tempest13:52
amoraleji agree we can probably clean some from tempest13:52
sean-k-mooneyi.e. the unit and fucntional test run in parallel13:52
sean-k-mooneydviroel: as we build our conficndnce in the fucntional tests the time to have tempest vs funcitonal will become more clear13:53
dviroelthis is already a huge improvement and something that we can focus in 2026.2 13:53
sean-k-mooneybasiclly negitive test i.e. tha tyou cant do somethign are almost never right to od in tempest13:53
sean-k-mooneyout side of some very basic api assetions13:53
sean-k-mooneybut funcitonal tests are great for that13:54
sean-k-mooneythey are also good for anything related to timeing issues or repoducing bugs that have interaction with multipel parts13:54
sean-k-mooneywe shoudl almos tnever have tempets test for bugs13:54
sean-k-mooneybut once you have funcitoal test lamost every bug shoudl start with a functional reguression test to demonstate teh bug and then prevent a regession13:55
sean-k-mooneyill stop talking now :) amoralej ++13:55
dviroelsince there is no bugs listed in the bugs topic, we can use this last 5 min for this, np13:55
dviroelunless someone want to mention any other review/bug13:56
dviroelamoralej: i guess that part of your your was based on nova's functional test infra? 13:56
dviroelthe standalone part is something only in watcher?13:56
amoralejyes, nova was the inspiration :) 13:56
amoralejyes the standalone is mine13:56
dviroelyeah, i didn't check how is implemented in nova..13:57
amoralejfrom my own experience having the option to run in standalone is good13:57
dviroelbut I remember that you mentioned13:57
dviroelamoralej: it is, when runnig scaling tests for example, it has been useful for me13:57
amoralejalso, i added an option to send logs for functional test to file, which i found useful when executing manually13:58
dviroelack13:58
dviroelany other comment around that?13:59
amoralejapart from that, the implementation follows the ideas from the spec and nova mostly13:59
dviroeland the reviews topic?13:59
amoraleji have one othe 13:59
dviroelsure13:59
amoralejabout https://review.opendev.org/c/openstack/watcher/+/994777 , note that that is related to cinder, where jgilaber is also working13:59
dviroelack14:00
amoralejso I'd propose to merge that ^ so that jgilaber can rebase on top14:00
amoralejunless it requires changes that make us go to the other way around14:00
dviroelack,  maybe we can also highlight in the status etherpad... I will take a look14:00
amoralejit's the equivalent to the change in nova model for zone_migrate14:00
amoraleji added into the bugfixes14:00
dviroelin openstack-sdk topic14:01
amoralejin the etherpad14:01
dviroelthanks amoralej 14:01
amoralejgood point14:01
dviroeloh, almost forgot:14:01
dviroel#topic Volunteers to chair next week14:01
dviroeli will be offline next week due to a holiday14:01
jgilaberI can do it14:01
dviroelneed someone to chair it14:01
dviroelthanks jgilaber 14:01
dviroellet's wrap up for today14:01
dviroelwe are out of time14:01
dviroelwe will meet again next week14:02
dviroelthank you all for participating14:02
dviroel#endmeeting14:02
opendevmeetMeeting ended Thu Jul  2 14:02:15 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:02
opendevmeetMinutes:        https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-07-02-13.00.html14:02
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-07-02-13.00.txt14:02
opendevmeetLog:            https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-07-02-13.00.log.html14:02
opendevreviewJoan Gilabert proposed openstack/watcher master: Remove unused CinderHelper methods  https://review.opendev.org/c/openstack/watcher/+/99484114:03
opendevreviewJoan Gilabert proposed openstack/watcher master: Add dataclass wrappers for CinderHelper API objects  https://review.opendev.org/c/openstack/watcher/+/99484214:03
opendevreviewJoan Gilabert proposed openstack/watcher master: Replace python-cinderclient with openstacksdk  https://review.opendev.org/c/openstack/watcher/+/99484314:03
opendevreviewJoan Gilabert proposed openstack/watcher master: Remove python-cinderclient dependency  https://review.opendev.org/c/openstack/watcher/+/99484414:03
opendevreviewJoan Gilabert proposed openstack/watcher master: Use real objects in volume migration tests  https://review.opendev.org/c/openstack/watcher/+/99486214:03
opendevreviewAlfredo Moralejo proposed openstack/watcher master: Remove Cinder API calls from zone_migration strategy  https://review.opendev.org/c/openstack/watcher/+/99477814:36
opendevreviewchandan kumar proposed openstack/watcher-dashboard master: Add Playwright integration test for skip action workflow  https://review.opendev.org/c/openstack/watcher-dashboard/+/97659414:47
amoralejsean-k-mooney, wrt dir names for fixtures, what if i use watcher/tests/local_fixtures for fixtures used both in unit and functional and watcher/tests/functional_fixtures for the ones only for functional?15:22
sean-k-mooneyamoralej: that was my orgianl propoasl15:28
sean-k-mooneywell not quite15:29
sean-k-mooneyi was proposing one for all fixture 15:29
sean-k-mooneyif you want to split it that is ok too15:29
amoralejit may be simpler to just put everything in one15:29
amoralejto avoid discuss if this is shared or common :) 15:29
sean-k-mooneyamoralej: basiclly eventlet used to prevent use singel step debuging through functional tests and unit test swithout hack15:30
sean-k-mooneyi really like that that now work again with the threaded mode15:30
sean-k-mooneybut i dont liek haveign to work aroudn the fixtures directory name issues15:30
sean-k-mooneyamoralej: so im fine with whatever name you chose15:31
sean-k-mooneyas long as its not "fixtures"15:31
amoralejin https://specs.openstack.org/openstack/watcher-specs/specs/2026.1/approved/functional-testing.html there is local_fixtures and fixtures, that's probably where i took that from, but doing all fixtures i local_fixtures seems the easiest path15:31
amoralejsaid that, in the spec local_fixtures was the place for the common ones15:31
amoralejand in https://gist.github.com/SeanMooney/43afa55282d2286a312eae7f3c7709e2 only mentions local_fixtures15:32
amoralejso i will do that15:32
sean-k-mooneyya in the gist i had alrady accouneted for this issue15:32
amoraleji'll do that, thanks!15:33
sean-k-mooneycool15:33
sean-k-mooneyi ned to quickly write a patch for cyborg for the enfoce socpe thing but ill try to do a fully review of your funtional test work tomowworw15:33
sean-k-mooneydviroel: we shoudl also review watchers policy by the way15:33
sean-k-mooneyi wont have a change to do it this week but we should ensure we are usign scopes properly before the end of the release15:34
sean-k-mooneylooking very quickly we are not usign them at all15:35
sean-k-mooneyso we may break15:35
sean-k-mooneyall of our api shoudl be project scope as a baseline15:35
sean-k-mooneywe can discuss supprot other scope later but that is the default15:36
sean-k-mooneythat means we need to add the scope defition to all our polices15:36
sean-k-mooneygmaan: ^ is there a default scope set in oslo.plocy that woudl be appled here https://github.com/openstack/watcher/blob/master/watcher/common/policies/action.py15:37
gmaansean-k-mooney: there is no default scope, if no scope_type in policy rule then oslo.policy will skip the scope enforcement15:37
sean-k-mooneyok so we can adress this later in the cycle15:38
gmaanit is mainly driven from policy rule, if scope is expected then oslo.policy check scope of token otherwise not15:38
gmaansean-k-mooney: yes15:38
sean-k-mooneyi have not really tought about if watch shoudl allwo system or doamin scoped tokens to use our api15:39
sean-k-mooneymy incliation is it has neve rbeen tested so no by default15:39
gmaank, yeah you can do it later and enforce_scope removal will not impact the policy who does not have scope yet15:39
sean-k-mooneyand default everythign to project and then we can consdier where to go form there15:39
gmaansounds good15:40
sean-k-mooneydviroel: after i remove the usage in cyrbog i might propose a poc of that for watcher in a week or two when i have time to get back to this15:40
sean-k-mooneywe can dicsus how to proceed in one of the irc meetings15:41
* dviroel back from lunch, reading back16:12
dviroelyeah, we can check that in the following weeks16:38
dviroelnot sure about system scoped, but project/domain scope I think that would require changes in how watcher manages resources..16:39
winiciusallan[m]sean-k-mooney: I believe I'll move to change the resource:<name> key to use placement allocation16:40
winiciusallan[m]so we can support passing GPU stuffs or other resources in the future16:40
winiciusallan[m]CUSTOM_NVIDIA_*, ...16:41
sean-k-mooneydviroel: so doamin im not sure about. nova does not supprot domain token for example so we might but we will have to thinking about it16:52
sean-k-mooneywiniciusallan[m]: that is ok but the reason i was defering that is that means we need to add the allcoation to the cluster data model for the instnace16:53
sean-k-mooneywe can do that, its not hard16:53
sean-k-mooneybut you are not allow to make rest api calls to placment durign the execution of the strage during an audit16:54
sean-k-mooneyso any data you need about hte intance need to be provie via the cluster data modle16:54
sean-k-mooneyit would not be hard to add this but just letting you know the wider context16:54
winiciusallan[m]sean-k-mooney: don't we have the flavor information in the CDM?16:55
sean-k-mooneywiniciusallan[m]: we do but that is not the same16:55
sean-k-mooneyim not refering to matich agaisnt resouce: flavor extra specs16:56
sean-k-mooneyallocation request for resouce come form many diffent locations16:56
sean-k-mooneyand direct resouce: usage in the flavor is discuraged16:57
sean-k-mooneythe only usage of it today is for the legacy vgpu supprot16:57
opendevreviewWinicius Allan Bezerra da Silva proposed openstack/watcher-specs master: Add spec for Preemptible Instances feature  https://review.opendev.org/c/openstack/watcher-specs/+/98717117:01
opendevreviewAlfredo Moralejo proposed openstack/watcher master: Move test fixtures to local_fixtures directory  https://review.opendev.org/c/openstack/watcher/+/98838818:42
opendevreviewAlfredo Moralejo proposed openstack/watcher master: Fix race condition in DefaultLoader._reload_config()  https://review.opendev.org/c/openstack/watcher/+/99484518:42
opendevreviewAlfredo Moralejo proposed openstack/watcher master: Add functional test framework for Watcher  https://review.opendev.org/c/openstack/watcher/+/98838918:42
opendevreviewAlfredo Moralejo proposed openstack/watcher master: Add Nova/Placement emulators and host_maintenance functional tests  https://review.opendev.org/c/openstack/watcher/+/99335218:42
opendevreviewAlfredo Moralejo proposed openstack/watcher master: Add Prometheus emulator and workload_stabilization functional tests  https://review.opendev.org/c/openstack/watcher/+/99354318:42
opendevreviewAlfredo Moralejo proposed openstack/watcher master: Add Cinder emulator and zone_migration functional tests  https://review.opendev.org/c/openstack/watcher/+/99363418:42

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