13:01:16 <dviroel> #startmeeting watcher
13:01:16 <opendevmeet> Meeting started Thu Aug 27 13:01:16 2026 UTC and is due to finish in 60 minutes.  The chair is dviroel. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:16 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:16 <opendevmeet> The meeting name has been set to 'watcher'
13:01:44 * dviroel was reviewing a code and almost missed the meeting start
13:01:51 <dviroel> hi all o/
13:01:55 <morenod> o/
13:02:07 <chandankumar> o/
13:02:44 <dviroel> courtesy ping:  sean-k-mooney rlandy
13:02:53 <dviroel> additional ping: winiciusallan[m]
13:02:55 <dviroel> :)
13:03:14 <dviroel> ok, so let's start with today's meeting agenda
13:03:28 <dviroel> #link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L34 (Meeting agenda)
13:03:36 <dviroel> feel free to add your own topics to the agenda
13:04:16 <dviroel> lets start with the first one
13:04:21 <dviroel> #topic Announcements
13:04:34 <dviroel> 1. Elections
13:04:47 <dviroel> just in case you missed:
13:04:48 <dviroel> Polls for TC elections are now open and will remain open for you to your vote until Sep 16, 2026 23:45 UTC
13:05:14 <dviroel> if you want to know if you are elegiblt to vote
13:05:27 <dviroel> check Ian email for more info
13:05:30 <dviroel> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/CU6SOGKPFEBTMGJ63T54G72E2MSJTZGG/
13:05:31 <winiciusallan[m]> o/
13:06:21 <dviroel> next announcement
13:06:27 <dviroel> 2. Hibiscus Schedule
13:06:35 <dviroel> #link https://releases.openstack.org/hibiscus/schedule.html
13:06:59 <dviroel> we reach hibiscus milestone-3
13:07:10 <dviroel> feature freeze is today
13:07:38 <dviroel> which mean that featureful patch should be landed after this point
13:08:04 <dviroel> but some expections may be granted by the ptl/core team
13:08:31 <dviroel> we should cover the open patch in the next topic
13:09:19 <dviroel> note that today is also the deadline for releasing client libraries
13:09:36 <dviroel> the python-watcherclient release patch is open
13:09:52 <dviroel> #link https://review.opendev.org/c/openstack/releases/+/1002075
13:10:27 <dviroel> we may go with current version, which adds audit-template default_parameters
13:10:37 <dviroel> but we can discuss that in a few
13:10:44 <dviroel> any other announcement?
13:11:09 <dviroel> #topic Reviews
13:11:22 <dviroel> startin with
13:11:23 <dviroel> #link https://review.opendev.org/c/openstack/watcher-dashboard/+/998131
13:11:44 <dviroel> morenod patch that adds new playwright tests
13:12:10 <morenod> yep. all requirements are now merged, we can review it
13:12:10 <dviroel> I think that I will have more time to review it next week, after we cover the features that we still need to land
13:12:17 <dviroel> nice, thanks for the work morenod
13:12:43 <dviroel> chandankumar: ptal also when yo have some time :)
13:13:06 <dviroel> ok, so next we can go through the reviews in the status etherpad
13:13:32 <dviroel> going to start with
13:13:32 <dviroel> 1. Preemtible Instances
13:13:39 <dviroel> since winiciusallan[m] is with us
13:13:47 <dviroel> so you splitted the changes
13:13:53 <dviroel> we have a proposal for 2 new actions
13:13:58 <dviroel> 1000168: Add new delete and shelve actions | https://review.opendev.org/c/openstack/watcher/+/1000168
13:14:08 <dviroel> which sean-k-mooney and I have been reviewing
13:14:27 <dviroel> it is in a good shape I think, and winiciusallan[m] has been updting based on our comments
13:14:33 <dviroel> so I guess that is close to be merged
13:14:37 <dviroel> likely today
13:15:01 <dviroel> winiciusallan[m]: so please fix the failing ci jobs
13:15:15 <winiciusallan[m]> i addressed most of your coments and from sean as well
13:15:17 <dviroel> winiciusallan[m]: what about the tempest change?
13:15:25 <winiciusallan[m]> yes, I just noticed that zuul failed
13:15:40 <dviroel> pep8, easy fix, no worries
13:15:50 <winiciusallan[m]> I have the devstack deployment, I'll debug why the tempest test is failing and will do my best to push this today
13:15:59 <dviroel> #link https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/1002188
13:16:32 <dviroel> ack, don't forget to add the config option for these new tests
13:16:46 <dviroel> since they can't be skipped based on api microversions
13:16:51 <winiciusallan[m]> yes, the flag option, right?
13:16:59 <dviroel> we need to skip them for all other stable branches
13:17:03 <dviroel> yes
13:17:09 <winiciusallan[m]> noted
13:17:26 <dviroel> let me know if you need help to setup the tempest on your local env
13:17:38 <dviroel> the next one is
13:17:40 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/1000170
13:17:51 <winiciusallan[m]> I'll probably need, but I ping you thanks
13:17:51 <dviroel> which adds the workload preemption strategy
13:18:38 <dviroel> I have been reviewing it, but there are still some threads that we raised some issues
13:18:52 <winiciusallan[m]> I left some questions mainly about filtering the instances
13:19:09 <dviroel> it is very likely that we will need a few more days to cover everything, not sure if sean-k-mooney will be able to review it today too
13:19:11 <winiciusallan[m]> If we would like to exclusively filter them by audit_scope of if we should do this in some way in the code
13:19:33 <sean-k-mooney> am i will be spending more tiem reviewing watcher today yes
13:19:57 <sean-k-mooney> if the issue in the first patch are adress ill look at the second
13:20:42 <dviroel> winiciusallan[m]: so i added a comment about "watcher_exclude=True", as teim-ci pointed out, we should not stop/shelve instances that have "watcher_exclude=True" since ther are exluded via scope
13:21:18 <dviroel> but they should be consider as resources allocated in the node/cluster
13:21:21 <sean-k-mooney> hum yes..
13:21:32 <sean-k-mooney> but i tough we expclied such instnace form the cdm
13:21:43 <sean-k-mooney> so they shoudl not be in the set of isntance the stragey sees?
13:22:17 <dviroel> they still exists in the cdm to strategies can account there resource allocation too
13:22:34 <sean-k-mooney> hum ok so that diffent the the compute nodes
13:22:47 <sean-k-mooney> which we just drop entirly
13:22:47 <dviroel> compute nodes are removed yes
13:22:50 <sean-k-mooney> ack
13:23:12 <sean-k-mooney> we may want a helper that returns only the "manageable instances"
13:23:18 <dviroel> correct
13:23:29 <sean-k-mooney> instead of implemnting that filtering in every stragey
13:23:30 <dviroel> in the cdm itself or in a additional strategy helper
13:23:36 <dviroel> yes
13:23:36 <sean-k-mooney> yep
13:23:54 <dviroel> we already have 3 bugs because of that
13:24:05 <dviroel> but for now, we need to avoid deleting thenm
13:24:11 <sean-k-mooney> ack on the resource_id vs server_id
13:24:24 <sean-k-mooney> so we need to revert back yes?
13:24:46 <dviroel> not sure if winiciusallan[m] already made that change
13:24:49 <sean-k-mooney> oh it wasnt actuly updated
13:24:54 <dviroel> yeah
13:25:06 <winiciusallan[m]> no, not yet
13:25:28 <winiciusallan[m]> becuase in the spec we are using resource_id, so I'd like to confirm if that's ok to rename it
13:25:41 <dviroel> i think that we can keep it
13:26:12 <sean-k-mooney> ya for now we can keep it as is
13:26:19 <sean-k-mooney> based on what dviroel noted
13:26:19 <dviroel> not sure if other places in the code really check RESOURCE_ID or hardcoded "resource_id"
13:26:30 <dviroel> so we may face issue
13:26:55 <dviroel> with more time we could try
13:27:05 <dviroel> for now, resource_id should be safer
13:27:10 <sean-k-mooney> it was a minor issue
13:27:18 <sean-k-mooney> it just looked like over generalisation
13:27:28 <sean-k-mooney> i.e. impliging it might be used to delete a volume or something later
13:27:31 <dviroel> ok, if winiciusallan[m] have time to keep working on these changes
13:27:36 <sean-k-mooney> i think we can ignore that comment
13:27:51 <dviroel> it is very likely that https://review.opendev.org/c/openstack/watcher/+/1000170 will need an exception
13:28:10 <dviroel> shelve/delete actions is feasible to get in I think
13:28:26 <dviroel> or not, lets see
13:28:35 <winiciusallan[m]> hope not :)
13:28:49 <dviroel> winiciusallan[m]: do you have some time early next week to update the patches if needed?
13:29:18 <winiciusallan[m]> yes! I'll be likely online on sunday and all monday
13:29:41 <dviroel> it more about the watcher changes, the tempest ones we can merge later, but would be good to have them validating the features
13:29:44 <dviroel> winiciusallan[m]: ack
13:30:10 <dviroel> sean-k-mooney and others, works for you?
13:30:16 <winiciusallan[m]> sean-k-mooney: PTAL when you have some time, your reviews are always valuable
13:30:26 <winiciusallan[m]> I'll try to do a quick turnaround
13:30:46 <dviroel> note that monday is holiday in some places, so few os us may not be around
13:31:00 <dviroel> we may have joan back on monday too
13:31:23 <dviroel> ok, so  lets keep reviewing it
13:31:31 <sean-k-mooney> dviroel: i think so
13:31:40 <dviroel> ack
13:31:48 <sean-k-mooney> i woudl be reluctant to extend beyond the next meeting but we can check in then
13:32:00 <dviroel> ah yes, me too
13:32:27 <dviroel> since winiciusallan[m] will be around, i think that we can solve most of the things earlier
13:32:31 <winiciusallan[m]> sounds good
13:32:38 <dviroel> next feature in the list
13:32:48 <dviroel> 2. Audit Pipeline
13:32:59 <dviroel> ah, this one has a lot of changes
13:33:31 <dviroel> #link https://review.opendev.org/q/topic:%22bp/audit-pipeline%22+is:+open
13:33:51 <dviroel> topic shows everything, including tempest and watcherclient
13:33:54 <dviroel> first thing
13:34:07 <dviroel> I don't think we will get the client merged this week
13:34:30 <dviroel> so we will likely need to wait to have 1.8 in the next release of the client
13:34:44 <dviroel> sean-k-mooney: ^
13:35:30 <dviroel> which is not a big issue, we also don't have the dashboard support for it yet (but I would like to propose in the next release too)
13:35:40 <sean-k-mooney> its ok for the client supprot to come later
13:35:56 <sean-k-mooney> it would not eb the first time that the client supprot landed in the cycle after an api feature
13:36:09 <sean-k-mooney> we prefer to avoid it but its not a blocker for the main feature to merge
13:36:19 <dviroel> yeah, I already faced the same thing in manila once
13:36:30 <sean-k-mooney> i have left some comment on the inial patch however
13:36:45 <sean-k-mooney> im not convice by the new interface fucntion yoru addign to the base stragies
13:37:22 <dviroel> i missed this i think
13:37:26 <dviroel> i was looking at the DB ones
13:37:44 <sean-k-mooney> DATASOURCE_METRICS is already aviabel as a class methond and you can access it directly from anywehre you can call get_datasouce_metrics
13:38:01 <dviroel> it is yes
13:38:08 <sean-k-mooney> also the get_perod(self,resouce) does not match the usage
13:38:17 <sean-k-mooney> almot noting passes resouce
13:38:28 <dviroel> some strategies allow period to be configures per resource
13:38:30 <sean-k-mooney> and often its just delegatin to a hard coded value or the property
13:38:33 <dviroel> as input parameters
13:38:41 <dviroel> that was the reason
13:39:12 <dviroel> so an strategy may have different period values based on the resource
13:39:12 <sean-k-mooney> right but this really does not look liek a clean interfce
13:39:22 <sean-k-mooney> if we are adopting thse fucntion we shoudl remove the properties
13:39:31 <sean-k-mooney> so we dont have 2 ways to get the same info
13:39:44 <dviroel> yeah, makes sense
13:39:56 <dviroel> we can replace them
13:40:12 <dviroel> i didn't remove to be backward compatible
13:40:42 <dviroel> is there a risk of breaking things outside the in tree strategies
13:40:52 <dviroel> or maybe deprecate the properties and remove later
13:41:00 <dviroel> instead of just remove them
13:41:04 <sean-k-mooney> well nothing outside the tree can inherit form the straties
13:41:15 <sean-k-mooney> the only one they can inertit form woudl be base
13:41:36 <sean-k-mooney> even then we do not really provide any stablity garentees to out of tree straties
13:42:21 <dviroel> correct, it seems that period and others are not part of the Base
13:42:33 <sean-k-mooney> correct
13:42:42 <dviroel> so it should be fine
13:42:45 <sean-k-mooney> also one fo the get_ fucntions i think never uses resouce
13:42:55 <sean-k-mooney> the other 2 i belive do in at least one case
13:44:13 <dviroel> ack, but if some strategy start to use it, we would add that later
13:44:16 <sean-k-mooney> oh no all 3 have 1+ usage
13:44:20 <dviroel> ah ok
13:44:26 <sean-k-mooney> ing genreal only one
13:44:33 <dviroel> i don't really remember the details
13:44:39 <sean-k-mooney> so if we clean up the duplciaiton i think its fine
13:44:42 <dviroel> but I remember that 1 or 2 use them
13:44:45 <dviroel> ack
13:44:59 <dviroel> agree, since Base does not have them
13:45:03 <sean-k-mooney> i woudl almost prefer to not use this and use the input parmater directly however
13:45:26 <sean-k-mooney> and just have constants for the kesy but this is ok
13:45:28 <dviroel> yeah, but input_paramters may not have a pattern to follow
13:45:31 <dviroel> yeah
13:45:39 <sean-k-mooney> i assume we will want to normalise this in the future
13:45:44 <dviroel> we should
13:45:49 <sean-k-mooney> i.e. make these supproted as input parmater on alls stragies
13:46:00 <sean-k-mooney> ok in that case the propoal makes more sense
13:46:11 <dviroel> still, the get_ could fetch dirctly from input_paramters later
13:46:13 <dviroel> yeah
13:46:26 <sean-k-mooney> yep and if we have a defautl we want to express we can do that
13:46:34 <sean-k-mooney> get(resouce,default)
13:46:41 <dviroel> we may discuss this more in the next ptg, wrt to filtering and base methods for strategies
13:46:46 <sean-k-mooney> ack
13:47:01 <sean-k-mooney> so the intial patch and db change were the two i looked at yesterday
13:47:08 <dviroel> thanks a lot
13:47:11 <sean-k-mooney> ill try and look deeper in the serise
13:47:27 <dviroel> i think that I agree with yout comments in  the DB patch
13:47:39 <dviroel> i think that i replied them
13:47:40 <sean-k-mooney> so what we could do
13:47:56 <sean-k-mooney> is proceed with the first patch as is, and you could do the property cleanup in a followup
13:48:06 <dviroel> yes
13:48:16 <sean-k-mooney> if you can push a draft for that on the end of the sereis ill swap to +2w
13:48:25 <dviroel> ack
13:48:31 <dviroel> easier  I think
13:48:46 <dviroel> since we already have Alfredo's vote
13:49:54 <dviroel> the DB patch, I implemented a bit different, not setting "name" as mandatory in the DB (so i also skipped the generated name for it, which is what Audit does)
13:50:07 <dviroel> but we can move to follow the Audit pattern
13:50:30 <dviroel> and turn a nullable=False and generate a name if user don't provide one
13:50:45 <dviroel> same for audit_stage
13:50:55 <dviroel> I think that covers most of your concerns
13:51:05 <dviroel> uniqueConstraints make sense too
13:51:09 <sean-k-mooney> we coudl jsut set the name to the pipeline name+ postion
13:51:18 <sean-k-mooney> if you dont provide one
13:51:34 <dviroel> audit aldo set datetime on them
13:51:56 <dviroel> e.g.: workload_balance-2026-07-17T17:38:03.755344
13:51:58 <sean-k-mooney> that might be because fo the contious audit and template interaction
13:52:09 <sean-k-mooney> if we did that on the pipelien
13:52:19 <sean-k-mooney> it woudl hapen automaticlly
13:52:21 <dviroel> name it is also an unique constraints I think
13:52:31 <dviroel> for audit
13:52:32 <sean-k-mooney> what did we say for the api
13:52:46 <sean-k-mooney> so i was expectign the api to require the name of the pipelien at a minium
13:52:57 <sean-k-mooney> but i dont recall what we said for stages
13:53:13 <dviroel> so for Audit name  is optional
13:53:36 <sean-k-mooney> ok well we do not need to requrie a name
13:53:36 <dviroel> so i was going in the same way for the AuditPipeline api
13:53:51 <dviroel> but we always populate one for Audits
13:54:00 <sean-k-mooney> the pipeline and postion is enough to enofroce the uiqueness of a stage
13:54:02 <dviroel> audit: https://docs.openstack.org/api-ref/resource-optimization/#id13
13:54:20 <dviroel> agree on the position+pipeline
13:54:27 <sean-k-mooney> ack im fine with takign the same approch
13:54:30 <dviroel> ack
13:54:50 <dviroel> i will update the code then in DB and in the API then
13:55:25 <dviroel> lets follow the same thing so it do not turns to be confusing
13:55:29 <dviroel> ack
13:55:37 <dviroel> the next thing would be the notifications patch
13:55:58 <dviroel> which can require some changes, but we could also do as follow up
13:56:50 <dviroel> the core change would be:
13:56:50 <dviroel> 1. https://review.opendev.org/c/openstack/watcher/+/1000031 Add AuditPipeline execution handler and cascade execution mode
13:56:55 <dviroel> the handle logic
13:57:09 <dviroel> 2. https://review.opendev.org/c/openstack/watcher/+/1001009 - Add efficacy indicators for Audit Pipeline action plans
13:57:11 <dviroel> and
13:57:29 <dviroel> 3. https://review.opendev.org/c/openstack/watcher/+/997427 - Add Audit Pipeline REST API endpoints
13:57:53 <dviroel> which I also didn't receive feedbacks from other reviewers
13:57:58 <sean-k-mooney> the only feedback i had on the notification patch is we proably over engenerired it and we shoudl get rid of the terse class
13:58:10 <sean-k-mooney> and jsut null out the stages when we want to be breif
13:58:20 <dviroel> it is possible
13:58:33 <sean-k-mooney> the thing is the class information is encode in the object
13:58:39 <dviroel> it is the way that other notifications were built
13:58:52 <sean-k-mooney> and im not sure client will wnat to have to treate the terse and verbose classes seperatly
13:59:15 <dviroel> yeah, the major difference is the stages info
13:59:19 <dviroel> that a client could ignore
13:59:44 <sean-k-mooney> we can declare it as a nullable/optional list of stage objects
14:00:03 <sean-k-mooney> and then the client can just check for null/None before trying to use it
14:00:09 <sean-k-mooney> that what we do in nova
14:00:22 <sean-k-mooney> but either is fien
14:00:28 <dviroel> ack
14:00:31 <sean-k-mooney> im not going to block on that
14:00:57 <sean-k-mooney> ill see if i can revew the remaining changes today
14:01:01 <dviroel> yeah, my feeling is that we saw some decisions in the past that we can improve, while adding new stuff
14:01:02 <sean-k-mooney> but i may not have tiem
14:01:12 <dviroel> ack thanks sean-k-mooney
14:01:22 <dviroel> so this is another feature that will require a FFE
14:01:27 <sean-k-mooney> we could follow the existing pattern for now and revist next cycle
14:01:52 <dviroel> there is a risk of not getting even next week, but that would be fine
14:02:04 <dviroel> we can see if Joan can also review it when he comes back
14:02:15 <sean-k-mooney> i think up until the next meeting woudl also be ok
14:02:24 <dviroel> alright
14:02:28 <sean-k-mooney> at which point i stongly suggest we punt
14:02:37 <sean-k-mooney> but yes joan will be back next week
14:02:46 <sean-k-mooney> so that allows another pair of eye to review
14:02:54 <dviroel> ack
14:03:08 <dviroel> before we close the meeting
14:03:21 <dviroel> since we also lack more reviewers for the client
14:03:33 <dviroel> I think  i will unblock the client release today
14:03:37 <dviroel> wdyt sean-k-mooney?
14:04:03 <sean-k-mooney> i think its fien for that to proceed
14:04:15 <dviroel> yeah, no need to rush things I guess
14:04:18 <sean-k-mooney> we can alwasy do an early release next cycle
14:04:23 <dviroel> righ
14:04:50 <dviroel> ok we are out of time
14:04:53 <sean-k-mooney> the other part of this
14:05:05 <dviroel> yeah?
14:05:05 <sean-k-mooney> is we will eventully need to add pipeline supprot to watcher-dashboard
14:05:17 <sean-k-mooney> so that will defintly not be this cycle
14:05:18 <dviroel> yeah, I mentioned that too
14:05:21 <sean-k-mooney> but that is ok
14:05:24 <dviroel> ack
14:05:40 <sean-k-mooney> well i asume you dont have it implemnted with playright tests?
14:05:44 <dviroel> we may have both next cycle, i can work in the dashboard
14:05:51 <dviroel> nope
14:05:59 <sean-k-mooney> ya i think its best to take our time with that
14:06:02 <sean-k-mooney> and not rush
14:06:08 <dviroel> ack
14:06:14 <dviroel> that was my idea too
14:06:30 <dviroel> so, et's wrap up for today
14:06:38 <dviroel> we can continue to chat here in the irc about the reviews
14:06:45 <dviroel> we will meet again next week
14:06:50 <dviroel> thank you all for participating
14:06:53 <dviroel> #endmeeting