12:00:58 <dviroel> #startmeeting watcher
12:00:58 <opendevmeet> Meeting started Thu Sep 11 12:00:58 2025 UTC and is due to finish in 60 minutes.  The chair is dviroel. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:58 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:58 <opendevmeet> The meeting name has been set to 'watcher'
12:01:22 <dviroel> hi all, lets see who is around today o/
12:02:02 <dviroel> courtesy ping: amoralej jgilaber sean-k-mooney chandankumar morenod rlandy
12:02:17 <morenod> o/
12:02:30 <sean-k-mooney> o/
12:02:31 <rlandy> o/
12:02:34 <dviroel> let's start with today's meeting agenda
12:02:45 <dviroel> #link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L33 (Meeting agenda)
12:03:18 <dviroel> feel free to add your own topics to the agenda
12:03:58 <dviroel> #topic Announcements
12:04:17 <dviroel> #link https://releases.openstack.org/flamingo/schedule.html
12:04:28 <dviroel> we are at RC1 target week
12:05:02 <dviroel> a new branch is expected, for 2025.2 release
12:05:23 <dviroel> which for now wil only receive release-critical issues
12:05:54 <dviroel> in case a critical bug is found during these days, until de final release
12:06:57 <dviroel> rc1 patch is ready, only waiting the prelude to merge
12:07:00 <dviroel> #link https://review.opendev.org/c/openstack/releases/+/960123
12:07:24 <dviroel> we can cover the prelude and cycle highlight patches in the next topic.
12:08:04 * dviroel prelude to merge, and hash to be updated in the release patch :)
12:08:16 <dviroel> ok, moving to the next announcement
12:08:23 <dviroel> this is a important one
12:08:34 <dviroel> Core team updates - removals, reminders, and new addition
12:08:57 <dviroel> just in case you missed this email from sean-k-mooney, in openstack-discuss ml
12:09:06 <dviroel> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QYX6OP2MAMKZ2LFYVCIEIZFRHO5ZKSAZ/
12:09:37 <dviroel> there are some updates proposed in this thread
12:10:03 <dviroel> 1. Immediate removals from cores that  have been inactive for an extended period time
12:10:34 <dviroel> 2. a new core proposal, for watcher-core group: jgilaber
12:11:01 <dviroel> and a notice, for more cores removal in future releases
12:11:38 <sean-k-mooney> ya so dviroel remieded me of the exact wording we said at the last ptg
12:11:59 <sean-k-mooney> i.e. that we woudl consider activey in the last 2 cycles as recent
12:12:07 <dviroel> +1
12:12:39 <sean-k-mooney> dviroel: also did the work to find the contibutors activeity dates
12:12:43 <sean-k-mooney> which helped a lot
12:12:50 <sean-k-mooney> i have not seen any objections
12:13:03 <sean-k-mooney> so unless there are any now
12:13:10 <sean-k-mooney> ill implement the changes after the meeting
12:13:51 <dviroel> anyone has any objections on both changes? removals and addition?
12:14:35 <dviroel> #agreed on removal of core reviewers have been inactive for more than 2 cycles
12:14:57 <dviroel> #agreed  on adding jgilaber to watcher-core group
12:15:24 <dviroel> jgilaber is out today, it is a public holiday in his location
12:15:43 <sean-k-mooney> going forward what i think we shoudl do is review this at the start of each slurp
12:16:06 <sean-k-mooney> and see who has not reviewd in teh prior slurp and who has but with very low activity
12:16:24 <dviroel> ++
12:16:27 <sean-k-mooney> this being the removals mainly
12:16:39 <sean-k-mooney> we can evaualte addtions on an ongoing basis
12:16:47 <dviroel> sure
12:17:11 <dviroel> sean-k-mooney: thanks for proposing these updates
12:17:23 <sean-k-mooney> no worries, i kind of have a related topic to this
12:17:33 <sean-k-mooney> but we can talk about that at the end if we have time
12:17:54 <dviroel> ACK
12:17:59 <dviroel> sorry, ack
12:18:02 <dviroel> jgilaber welcome, and thanks for the help with reviews o/
12:18:11 <dviroel> moving to the next topic
12:18:29 <dviroel> #topic reviews
12:18:41 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/960298 (relese note prelude)
12:19:10 <dviroel> this is the release prelude, thanks sean-k-mooney for proposing
12:19:20 <dviroel> we can see it rendered here https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_e20/openstack/e2080f4dda5044b18871da18757bb77f/docs/unreleased.html
12:19:27 <dviroel> lgtm
12:19:46 <dviroel> we need to merge it soon, to proceed with the rc1 release
12:20:26 <sean-k-mooney> yes. again if there are no objects i wil likely merge it later today
12:20:27 <dviroel> please folks, review it now while we still have some time
12:20:36 <dviroel> ++
12:20:53 <sean-k-mooney> once its merged ill update the sha in the rc1 release patch with it
12:21:01 <dviroel> great, thanks!
12:21:10 <dviroel> the next one is the cycle highlights
12:21:16 <dviroel> #link https://review.opendev.org/c/openstack/releases/+/960325 (cycle highlights)
12:21:39 <dviroel> which should merge soon
12:21:55 <dviroel> since was W+1 minutes ago
12:22:22 <dviroel> I added a comment about some possible additions, but I think that the patch covers the most important ones
12:22:30 <dviroel> thanks again for proposing sean-k-mooney
12:22:51 <sean-k-mooney> so next cycle these will fall to our new release liasons to do
12:22:56 <sean-k-mooney> but i wanted to compelt htem for this cycle
12:23:25 <sean-k-mooney> this is almost hte last of the release work for this cycle
12:23:26 <dviroel> +1
12:23:40 <sean-k-mooney> the last part, which was goign to be my other topic
12:24:02 <sean-k-mooney> is we need to update the specs repo, and create teh launchpad series for 2026.1
12:24:17 <sean-k-mooney> the bit i wanted to dicuss was
12:24:38 <sean-k-mooney> should i add other to the launchpad group for the seirs cration
12:24:41 <sean-k-mooney> or not
12:25:29 <sean-k-mooney> currently its myself and checkner
12:25:31 <sean-k-mooney> https://launchpad.net/~watcher-drivers/+members
12:25:31 <dviroel> yeah, I do think so
12:25:58 <sean-k-mooney> so if i do, shoudl it be the cores or the release liasosn
12:26:02 <sean-k-mooney> or both
12:26:33 <dviroel> we can assign the series creation task to the liasons I think
12:26:35 <sean-k-mooney> we can table this till next weeks irc meeting if we want
12:27:05 <sean-k-mooney> ya its actully listed in the release liaosn guide i created
12:27:06 <dviroel> we currently have 2 active liasons, which can split the work
12:27:25 <sean-k-mooney> ack
12:27:28 <rlandy> chandan in out until next week
12:27:38 <sean-k-mooney> ya i was just going ot do it this cycle
12:27:48 <dviroel> i would say that we can have at least one or 2 cores to help as admins of this group
12:27:54 <sean-k-mooney> but i can add them so they can do it going forward
12:27:55 <dviroel> and the liasons to do the work
12:28:12 <sean-k-mooney> ok that works for me
12:28:16 <dviroel> +1
12:28:34 <dviroel> about the watcher-specs updates
12:28:38 <dviroel> #link https://review.opendev.org/c/openstack/watcher-specs/+/960177
12:29:09 <dviroel> I proposed this patch, but needs another eyes to see if I am missing something
12:29:11 <sean-k-mooney> oh great you did have time to create it
12:30:01 <sean-k-mooney> skiming it it looks ok but ill review it properly later
12:30:09 <dviroel> ack, tks
12:30:36 <sean-k-mooney> i think going forward we shoudl do this in 2 steps
12:30:51 <sean-k-mooney> wehn we pass spec freeze at milestone 2
12:31:00 <sean-k-mooney> we shoudl create the spec dir for the next cycle
12:31:27 <sean-k-mooney> and then all that is needed at FF+1 shoudl be moving the implmented spec and redirects
12:31:50 <sean-k-mooney> doing it all in one patch is also fine
12:31:50 <dviroel> makes sense, since we can move propose specs to the next cycle, if they don't fit in the current one
12:31:58 <sean-k-mooney> exactly
12:32:10 <dviroel> +1
12:32:23 <sean-k-mooney> it elimiates the potital for a review gap if we have context loaded
12:33:05 <sean-k-mooney> anything else on release topics
12:33:11 <sean-k-mooney> if not we can move on i think
12:33:19 <dviroel> sure, lets move
12:33:40 <dviroel> #topic Bug Triage
12:33:50 <dviroel> here I added a lot of open bugs
12:33:58 <dviroel> which we may not have time to cover today
12:34:05 <dviroel> but then I will move to next meeting agenda
12:34:22 <dviroel> #link https://bugs.launchpad.net/watcher/+bug/2122347 (No CORS support)
12:34:50 <dviroel> tkajinam open this one, and raised the issue here in the channel
12:35:16 <dviroel> the thing is that currently watcher does not support CORS middleware
12:35:19 <opendevreview> OpenStack Release Bot proposed openstack/watcher-dashboard stable/2025.2: Update .gitreview for stable/2025.2  https://review.opendev.org/c/openstack/watcher-dashboard/+/960523
12:35:21 <opendevreview> OpenStack Release Bot proposed openstack/watcher-dashboard stable/2025.2: Update TOX_CONSTRAINTS_FILE for stable/2025.2  https://review.opendev.org/c/openstack/watcher-dashboard/+/960524
12:35:23 <opendevreview> OpenStack Release Bot proposed openstack/watcher-dashboard master: Update master for stable/2025.2  https://review.opendev.org/c/openstack/watcher-dashboard/+/960525
12:36:13 * dviroel bot drained my attention
12:36:32 <sean-k-mooney> ya i was also lookign at those in other channels.
12:36:59 <sean-k-mooney> ya so i think its imporant to add supprot for cors at least somewhat natively
12:37:20 <sean-k-mooney> its possibel to do this in teh websever but that not how all the rest of openstack works
12:37:42 <sean-k-mooney> so we shoudl try not to make watcher special
12:37:55 <sean-k-mooney> im unsure if we shoudl consdier backporting this or not.
12:38:09 <sean-k-mooney> thsi si technialy a feature and woudl be an expction to the policy
12:38:16 <dviroel> yeah, this is an important discussion to have (the backporting)
12:38:40 <sean-k-mooney> so my proposal is let dicuss that spereatly after we are happy with the change and the testing fo the change
12:39:18 <dviroel> the patch is proposed btw
12:39:27 <sean-k-mooney> its is yes
12:39:36 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/960044
12:39:46 * dviroel it took some time to open the LP here
12:40:05 <sean-k-mooney> it does nto tweak ci to test the chagne.
12:40:27 <sean-k-mooney> i was undecieed if i wanted to ask takashi to do that or just do that ourselve in a follow up
12:40:32 <sean-k-mooney> given they are busy with other things
12:40:57 <sean-k-mooney> i was leanign towrads doign it in a follow up
12:41:08 <dviroel> yeah we can split the work here, and propose the ci testing
12:42:02 <sean-k-mooney> we do actully have the tls proxy enabled
12:42:04 <sean-k-mooney> https://b56ae66d8d1228f47a8b-8be9667f5530aa8ec0c6e8c86da1b76d.ssl.cf1.rackcdn.com/openstack/f7310413ea7642ef81922e59abaece31/controller/logs/local_conf.txt
12:42:27 <sean-k-mooney> im just not sure if we shoudl ahve other testing and if we have cors configuredc in the job
12:42:47 <sean-k-mooney> so that woudl eb the scope fo the follow up which ties into the next bug i think
12:43:17 <dviroel> ack
12:43:29 <dviroel> we already have the importance set in the CORS one
12:43:32 <dviroel> moving to the next
12:43:41 <dviroel> #link https://bugs.launchpad.net/watcher/+bug/2122353 (links in response contain wrong protocol when standalone api...)
12:44:06 <sean-k-mooney> so we have a few options here.
12:44:23 <sean-k-mooney> first this will be fixed as a side effect of the CORS patch i belive
12:44:44 <sean-k-mooney> but standaloen api here means eventlet
12:44:48 <dviroel> hum
12:44:58 <sean-k-mooney> which we have deprecated and plan to remove
12:45:00 <dviroel> right, which is deprecated
12:45:17 <sean-k-mooney> so we coudl chosoe to not fix this
12:45:42 <sean-k-mooney> oh im wrong
12:45:57 <sean-k-mooney> the fix is to use  http_proxy_to_wsgi middleware
12:46:07 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/960157
12:46:18 <sean-k-mooney> oh so no
12:46:26 <sean-k-mooney> that uses to be in the cors patch in v1
12:46:39 <sean-k-mooney> takashi split that out so it can be backported sepetately
12:47:18 <sean-k-mooney> dviroel: soim inclided to say valid and medium
12:47:29 <sean-k-mooney> and we shoudl backport that
12:47:49 <dviroel> ok, updating the bug then
12:48:00 <dviroel> I will need to take a look with more time on that
12:48:10 <sean-k-mooney> the only issue i see is its currently  the 3rd patch in the chain
12:48:20 <sean-k-mooney> after the cores work and the requeit id change
12:48:46 <dviroel> which brings us to the next bug
12:48:53 <sean-k-mooney> :)
12:48:59 <dviroel> #link https://bugs.launchpad.net/watcher/+bug/2122350 (x-openstack-request-id header is not included in response headers)
12:49:17 <sean-k-mooney> ya so this si important for debuging
12:49:23 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/960154
12:49:28 <sean-k-mooney> so that you can trace calss across services
12:49:30 <dviroel> yeah, this is very helpful
12:49:33 <sean-k-mooney> as the request id is the same end to end
12:49:47 <dviroel> this is really a missing thing on watcher
12:49:49 <sean-k-mooney> so agin i woudl triage as medium
12:50:13 <sean-k-mooney> operaationally this is imporant to debug problems in production properly
12:50:56 <sean-k-mooney> over all im leanign towards sayign we shoudl backprot all 3 or we shoudl ask takasi to put the cors patch at teh end instead of the start
12:50:58 <dviroel> ++
12:51:54 <sean-k-mooney> the reaon these depend on each other today is the cors path add a depency on oslo.middleware
12:52:18 <sean-k-mooney> which i think is why the content provider job is failign because we will need to update teh watcher spec file
12:53:44 <sean-k-mooney> adding that dep escpially since they are adding a very old verion of it as the min requireemnt (which is valid for the satble branches too)
12:53:46 <dviroel> so the idea of putting the cors at the end is that we may or may not backport it?
12:53:47 <sean-k-mooney> shodul be ok
12:53:55 <sean-k-mooney> yep
12:54:15 <sean-k-mooney> it allwos use to deferr that if we want to backprot the other two
12:54:20 <sean-k-mooney> which are more clear cut to me
12:54:21 <dviroel> ack, sounds like a good plan
12:54:24 <dviroel> agree
12:54:45 <sean-k-mooney> lets try and capature that in the gerrti review
12:55:01 <sean-k-mooney> tkajinam: ^ but if you do have time to read back hopefully that works for you too
12:55:25 <dviroel> anything else to add wrt these bugs? I think we can cover at least one more
12:55:55 <dviroel> #link https://blueprints.launchpad.net/watcher/+spec/instance-live-migration-timeout
12:56:07 <dviroel> this is a possible bug :)
12:56:17 <sean-k-mooney> ya so i have nto converted it yet
12:56:30 <sean-k-mooney> i went through all the old still open blueprint durign the week
12:56:37 <sean-k-mooney> and marked them obsolete
12:56:42 <sean-k-mooney> btu i found this whiel doing that
12:56:56 <sean-k-mooney> i have checked and as far as i can tell the report is still correct
12:57:06 <dviroel> hum, that the timeout is 120 seconds (hard coded)
12:57:11 <sean-k-mooney> we take the time out as a keywrod arg and default to 120
12:57:23 <sean-k-mooney> but we never pass that keyword arge anywhere
12:57:28 <sean-k-mooney> so yes its effectivly ahrdcoded
12:57:32 <sean-k-mooney> unless i missed it
12:57:46 <sean-k-mooney> the question however is how to fix it
12:58:10 <sean-k-mooney> if we add a config option or more so if we add a stragey parmater
12:58:30 <dviroel> or both
12:58:30 <sean-k-mooney> this puts it into feature or master only territory
12:58:52 <sean-k-mooney> ya or both a defautl in the config with an overried in teh audit
12:59:12 <sean-k-mooney> so i dont know if this shoudl eb a bug
12:59:21 <sean-k-mooney> or a feature but i suspect we need a general solution
12:59:49 <sean-k-mooney> i.e. for other operations as well. so maybe somethign we need to investiage
13:00:30 <sean-k-mooney> we can revisit or dicuss outside the meeting
13:00:43 <sean-k-mooney> just wanted to highlight it
13:01:13 <dviroel> i would say that we should at least have a proposal that we can backport, this can be a blocker for some operators that want to use watcher, since migration is the most important/used action
13:01:27 <dviroel> maybe split in two different solutions
13:01:40 <dviroel> but something that we can discuss afterwards, yes
13:02:25 <sean-k-mooney> agreed on both fronts
13:02:33 <sean-k-mooney> we are at/over time
13:02:40 <sean-k-mooney> do we want to contineu or wrap up
13:02:59 <dviroel> lets wrap
13:03:08 <dviroel> and move the remaining bugs to the next weel
13:03:38 <dviroel> tks rlandy for volunteering to chair next week
13:03:44 <dviroel> i will be also available if needed
13:03:52 <dviroel> thank you all for participating
13:04:01 <dviroel> we will meet again next week o/
13:04:07 <dviroel> #endmeeting