| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Add Playwright integration test for skip action workflow https://review.opendev.org/c/openstack/watcher-dashboard/+/976594 | 10:41 |
|---|---|---|
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Add OSProfiler support for cross-service tracing https://review.opendev.org/c/openstack/watcher/+/976280 | 10:46 |
| opendevreview | Merged openstack/watcher stable/2025.2: Allow volume and vm migrations in zone_migration https://review.opendev.org/c/openstack/watcher/+/961441 | 10:49 |
| dviroel | hi all, watcher meeting will start in 15min in this channel. Please add your topics to the meeting etherpad: https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L28 | 11:46 |
| opendevreview | Merged openstack/watcher stable/2025.2: Make VM resize timeout configurable with migration defaults https://review.opendev.org/c/openstack/watcher/+/969877 | 11:50 |
| opendevreview | Merged openstack/watcher stable/2025.2: update unit tests for nova_helper module https://review.opendev.org/c/openstack/watcher/+/971397 | 11:51 |
| opendevreview | Merged openstack/watcher stable/2025.2: Retry calls to nova API when connection errors are detected https://review.opendev.org/c/openstack/watcher/+/971398 | 11:51 |
| dviroel | #startmeeting watcher | 12:00 |
| opendevmeet | Meeting started Thu Feb 12 12:00:13 2026 UTC and is due to finish in 60 minutes. The chair is dviroel. Information about MeetBot at http://wiki.debian.org/MeetBot. | 12:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 12:00 |
| opendevmeet | The meeting name has been set to 'watcher' | 12:00 |
| dviroel | hi all o/ | 12:00 |
| chandankumar | o/ | 12:00 |
| jgilaber | o/ | 12:00 |
| rlandy | o/ | 12:01 |
| morenod | o/ | 12:01 |
| dviroel | courtesy ping: amoralej sean-k-mooney | 12:02 |
| dviroel | ty all for joining | 12:02 |
| dviroel | let's start with today's meeting agenda | 12:02 |
| dviroel | #link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L28 | 12:02 |
| dviroel | feel free to add your own topics to the agenda | 12:02 |
| dviroel | #topic Announcements | 12:03 |
| dviroel | Gazpacho Schedule | 12:03 |
| dviroel | it is good to always check our deadlines within the release | 12:03 |
| dviroel | feature freeze is in two weeks from now | 12:04 |
| dviroel | after that, no features should be landed in master until the release | 12:04 |
| dviroel | do based on that, we should focus on the pending changes that are ready for review | 12:05 |
| dviroel | we can check that in a few, during the review topic | 12:05 |
| sean-k-mooney | +1 | 12:06 |
| dviroel | if there is no other announcement we can go to the next topic | 12:06 |
| dviroel | #topic Nova_helper interface | 12:07 |
| dviroel | hey jgilaber o/ | 12:07 |
| jgilaber | hey! | 12:07 |
| jgilaber | thanks for the reviews on https://review.opendev.org/c/openstack/watcher/+/972913 | 12:08 |
| jgilaber | we've had a few discussions and I'd like to bring up which should be the desired behaviour from the nova_helper methods | 12:08 |
| jgilaber | when getting an error from the nova api for a instance not found for example | 12:08 |
| jgilaber | currently it would rise an exception, however in some calls it would check if the return is None | 12:09 |
| jgilaber | the current version of the patch does a mix, it catches the NotFound errors and returns None, while catching other errors from the client and returning a Watcher exepction | 12:10 |
| amoralej_ | o/ | 12:10 |
| jgilaber | another option would be to go back to always raising using Watcher exceptions and fix the places where it checks for None | 12:10 |
| amoralej_ | sorry for the delay | 12:10 |
| jgilaber | I wanted to bring it up here in a medium with lower latency to hopefully agree on an approach and update the patch | 12:11 |
| dviroel | i think that you can't avoid some exceptions, but when you get a NotFound, you are returning None now (and before was raising the NotFound) | 12:12 |
| dviroel | in the proposed patch | 12:13 |
| jgilaber | yes, that's right | 12:13 |
| dviroel | which I think that nobody (yet) disagree with the approach | 12:13 |
| amoralej_ | i like the idea of keeping the behavior closer to the previous one, which was raising an exception | 12:13 |
| sean-k-mooney | im ok with changign it but not in this serises if im being honest | 12:13 |
| dviroel | but once we decide to change the interface, we should also make all other interfaces behave in the same way | 12:14 |
| amoralej_ | specifically for the find_instance i.e., currently (before openstacksdk) is raising a novaclient exception, my preference would be to keep raising an exception, a new watcher one | 12:14 |
| sean-k-mooney | returnign none is oke but we shoudl not change the behivor in the same patch that changes to the new client/data stuctures | 12:14 |
| sean-k-mooney | so by definiton refactoring is the changein of the inernal wihtout chanig its public interface | 12:15 |
| amoralej_ | but, if he raises a exception, should fix the places where it checks if it's none? | 12:15 |
| dviroel | right, the new return is adding much more code change to the patch, which makes more dificult to review | 12:15 |
| sean-k-mooney | amoralej_: yes so the code before this patch alway raises | 12:15 |
| sean-k-mooney | now we dont catch that in some places wihc is a bug | 12:15 |
| amoralej_ | yep | 12:15 |
| sean-k-mooney | but we can and shoudl adress that in a diffent patch | 12:16 |
| jgilaber | ack, so the consensus is to keep raising an exception, I'll update the patch with that approach, thanks! | 12:16 |
| sean-k-mooney | yes i woudl keep raisign until after the serise to remove nova clinet is fully merged | 12:17 |
| sean-k-mooney | then we can change the interface if we want later | 12:17 |
| sean-k-mooney | just so we dotn have to reason about both changes at once | 12:17 |
| dviroel | the same is valid for Actions right? | 12:17 |
| dviroel | to not change the behavior in this series of patches? | 12:18 |
| sean-k-mooney | yes | 12:18 |
| amoralej_ | btw, should we have a common NotFound exception instead of InstanceNotFound ? | 12:18 |
| amoralej_ | dviroel, yes, we shouldn't | 12:18 |
| sean-k-mooney | what i would suggest is create an etherpad with bugs.finding that need to be adressed | 12:18 |
| jgilaber | amoralej_, yes I was planning to crate a generic NotFound exception to raise | 12:18 |
| amoralej_ | good | 12:19 |
| sean-k-mooney | i guess that is ok | 12:19 |
| amoralej_ | and for other errors? ClientError or something like that ? | 12:19 |
| dviroel | jgilaber: +1 | 12:19 |
| jgilaber | in the current patch I added a NovaClientError | 12:19 |
| amoralej_ | good | 12:19 |
| amoralej_ | sorry, i missed that one | 12:19 |
| sean-k-mooney | there may be cause where we want to differecate but i woudl make InstanceNotFound inherit form NotFound | 12:19 |
| jgilaber | but can make it also more generic for when we do the same for cinder, keystone, etc. | 12:19 |
| amoralej_ | something that i need to check is if the exceptions we use in nova_retries decorator are valid for openstacksdk too | 12:20 |
| amoralej_ | unless you did :) | 12:21 |
| sean-k-mooney | they proably are not but you can catch a tuple of excption so they can be extended to work for both | 12:21 |
| jgilaber | I think I did not change that, but it should be easy to fix | 12:21 |
| amoralej_ | novaclient rased keystoneauth one, so maybe | 12:21 |
| sean-k-mooney | although it despned on when we do the convertion i.e we shoudl likely do the conversion to the new watcher ones before we hit that | 12:21 |
| dviroel | ok so jgilaber is going to work on that and propose a new patch | 12:24 |
| dviroel | a series of updates :) | 12:25 |
| dviroel | #link https://review.opendev.org/q/topic:%22use-openstacksdk%22+project:+openstack/watcher | 12:25 |
| jgilaber | yes, I think we can move to the next topic | 12:25 |
| jgilaber | thanks all! | 12:25 |
| dviroel | ack | 12:25 |
| dviroel | #topic 2025.2 new release | 12:25 |
| dviroel | so jgilaber is mentioning that we are recently merging a lot of patches/fixes in 2025.2 | 12:26 |
| jgilaber | yes, IIRC there only 5 pending and are all approved | 12:26 |
| jgilaber | so we should have everything in by eow | 12:27 |
| dviroel | ack, due to recent issue with setuptools, some patches were delayed | 12:27 |
| jgilaber | do we want to make a release once those are merged? | 12:27 |
| dviroel | shold we consider a new release of 2025.2 after that? | 12:27 |
| dviroel | do we have more patches for 2025.2 that can be merged? I think that I cover most of them, but I need to check again | 12:28 |
| dviroel | or we could wait to get more backports to 2025.1 and do both releases | 12:28 |
| jgilaber | for 2025.2 all are approved https://review.opendev.org/q/project:openstack/watcher+branch:stable/2025.2+status:open | 12:29 |
| jgilaber | we have quite a lot more for 2025.1 though https://review.opendev.org/q/project:openstack/watcher+branch:stable/2025.1+status:open | 12:30 |
| sean-k-mooney | i think we have most in the pipeline | 12:30 |
| dviroel | ack, so I am fine with a new release, because I believe that we are going to have more time to start reviewing 2025.1 ones | 12:30 |
| dviroel | s/to have/need | 12:30 |
| jgilaber | ack, so if noone is against it, I'll make the patch for the 2025.2 relase once the current patches merge | 12:31 |
| amoralej_ | +1 | 12:31 |
| dviroel | ok, I think that we can move to the next topic then | 12:32 |
| dviroel | fungi added a topic | 12:33 |
| dviroel | #topic Bridging the Gap Flamingo Cycle Retrospective | 12:33 |
| fungi | ildiko posted openstack-wide 2025.2 (flamingo) cycle retrospective contributor/maintainer survey results and metrics to openstack-discuss last month: | 12:33 |
| fungi | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/XZZYFHMUCB3IZU5AXM366AY7WJXQMTBX/ Bridging the Gap Flamingo Cycle Retrospective Survey Results | 12:33 |
| fungi | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/FD4JALJN7OB2YNBUVWCPZZ6YNJMIL2JT/ Bridging the Gap Flamingo Cycle Retrospective Metrics Analysis | 12:33 |
| fungi | i and the other community managers on the openinfra foundation staff have also been digging into team-specific details and i'm doing a round of outreach similar to last cycle, to go over how things may have changed | 12:33 |
| fungi | the watcher team had 1 contributor and 1 maintainer fill out the surveys, more would still be better of course, but this is a good start nonetheless | 12:33 |
| fungi | the contributor self-identified as new to watcher, but contributes to 2 or more other open source projects | 12:33 |
| fungi | ratings on the contributor survey questions were positive overall, with actionable review feedback, test results and helpful contributor docs the highest at 5 out of 5, but navigability of the contributor docs lowest with 3 out of 5 | 12:33 |
| fungi | this contributor appreciated how welcoming and friendly the watcher team is, and how smooth they felt the contribution process went | 12:33 |
| fungi | the biggest challenge to contributing was older code patterns clashing with new paradigms, leading to necessary refactoring or contortions to keep additions consistent with what's already there (likely adding further technical debt) | 12:34 |
| fungi | the new survey questions about priorities were insightful: the contributor said they follow development and prioritization through specs, launchpad blueprints, gerrit change topics, gerrit hashtags, and irc/mailing list discussions | 12:34 |
| fungi | by comparison, the maintainer response was nearly identical, but additionally indicated communicating priorities through etherpad or a similar collaborative document as well as custom review dashboards or queries (and omitted hashtags) | 12:34 |
| fungi | the rankings on the maintainer survey response were similarly positive, with 4 out of 5 on almost everything, except comprehensiveness of the contributor docs at only 3 out of 5 | 12:34 |
| fungi | the maintainer's primary challenge in contributing changes was the small core team struggling to find review bandwidth, and resorting to single-core approvals in order to have enough remaining time to make progress on development | 12:34 |
| fungi | the maintainer's challenges in reviewing were change owners not addressing feedback in a timely manner, changes lacking tests/docs/release notes, or needing specs/blueprints | 12:34 |
| fungi | additional feedback from the maintainer indicated a need for participants to set clear boundaries for their availability (especially when spread across other project teams), and improving communication internally as well as cross-project | 12:35 |
| fungi | as for metrics, changes were merged twice as fast in flamingo vs in epoxy, and initial reviews were 5x faster | 12:35 |
| fungi | active reviewers count fell by 20% and active maintainers fell by 40% in flamingo compared to epoxy, though both were in line with or better than dalmatian and far better than earlier cycles, so epoxy looks like the anomaly in that regard | 12:35 |
| fungi | only 92% as many changes were closed as opened in flamingo so the team isn't quite keeping up with volume there, but is doing surprisingly well in handling more than double the number of changes as in epoxy (even with fewer maintainers!) | 12:35 |
| fungi | the community managers have been distilling feedback from last year's discussions, and are working on compiling a concise set of techniques/recommendations for improving communication and efficiency, which i can get into more next week | 12:35 |
| fungi | we're also hoping to get some case studies done in concert with successful contributors and maintainers to highlight how specific practices and behaviors help them achieve better throughput, in hopes of being able to replicate them | 12:35 |
| fungi | anyway, that was a quick dump, i know it's a lot to take in but i didn't want to eat up too much of your meeting, so i'll put this on the agenda again for next week to give everyone time to digest and come up with questions or ideas | 12:35 |
| fungi | though i'm happy to answer any immediate feedback now if there's time | 12:36 |
| sean-k-mooney | we had 2 redhater move on form openstack in eh epoxy cyclie i think although that may have been dalmation | 12:37 |
| sean-k-mooney | so that accound for some of the decrease in reviewers | 12:37 |
| sean-k-mooney | alhtough jgilaber has joined the core team since | 12:37 |
| fungi | well, if they were active in some part of epoxy then they would have counted as active for that cycle | 12:37 |
| jgilaber | does maintainer==core reviewer in this context? | 12:38 |
| fungi | basically, "active" maintainers are anyone who used a code review +2/-2 or workflow +1 on at least one change for any repository belonging to the team | 12:38 |
| sean-k-mooney | there are two forms so kind of | 12:38 |
| sean-k-mooney | ah well in that sense also yes | 12:38 |
| sean-k-mooney | when you file out the survay you self select into the group dependign on what you select | 12:39 |
| fungi | by measuring that way, we're drawing a distinction between people who have permission to do core review work and people who actually used that permission | 12:39 |
| sean-k-mooney | i dont thinkthat is enforce anywehre but i allwasy assumed that maintaienr=core | 12:39 |
| fungi | and yes, the survey responses are self-identifying as a maintainer or a non-maintainer code contributor | 12:39 |
| sean-k-mooney | while i dont like to depend on singel core approval i is somethign that pragmaticly is justifyibel given smaller review teams | 12:41 |
| sean-k-mooney | it would be nice if eventually we had more diversity in the core team i.e. other companies | 12:41 |
| fungi | i'll note that we counted 6 people who did code-review +2/-2 or workflow +1 on changes in watcher's repos during flamingo, and 10 in epoxy | 12:42 |
| sean-k-mooney | is that something that ye are lookign at in general across projects? | 12:42 |
| dviroel | I think that early in epoxy cycle, only sean-k-mooney was core in the team | 12:42 |
| fungi | but most of those may have been only very minimally active | 12:42 |
| opendevreview | Merged openstack/watcher master: Change id field to uuid when appropiate https://review.opendev.org/c/openstack/watcher/+/975200 | 12:42 |
| sean-k-mooney | there were others like dan and gmann and others form the tc | 12:42 |
| sean-k-mooney | and inactive cores | 12:43 |
| sean-k-mooney | but ya i think marious had core rights but they had moved on eform openstack | 12:43 |
| fungi | sean-k-mooney: we didn't analyze maintainer affiliations, but i think we could (with a caveat that probably only 2/3 of maintainers will probably have indicated an affiliation in their foundation profiles, and those may also not be accurate/current) | 12:43 |
| sean-k-mooney | im not sure why martin was added and when they moved on ot ohter proejcts | 12:43 |
| sean-k-mooney | on a related note | 12:44 |
| sean-k-mooney | there was a conversation about the users survey | 12:44 |
| sean-k-mooney | and updating the question by removing old ones and having project opt in | 12:45 |
| fungi | also something we have to consider when we look at measuring new facets of this is whether it's going to be possible in lfx insights, as opposed to bitergia where we were previously querying things (we're at least working to get the things we already measured available through insights) | 12:45 |
| sean-k-mooney | we have not participated in the user survey since reviving watcher i think it woudl be good for use to reach out to allison? about that | 12:45 |
| fungi | sean-k-mooney: yes, allison price is coordinating with the tc to get the user survey revamped later this year | 12:46 |
| sean-k-mooney | fungi: ya i looke at lfx during the week | 12:46 |
| sean-k-mooney | fungi: form my perspective the current dashboards are not useful | 12:46 |
| fungi | i believe the plan is to discuss user survey work in detail at the ptg | 12:46 |
| sean-k-mooney | or minimally so | 12:46 |
| sean-k-mooney | ack good to know i think we shoudl try an attend that session in some capasity | 12:46 |
| dviroel | +1 | 12:46 |
| fungi | absolutely, she's also asked the tc to help coordinate outreach to and feedback from team leaders | 12:47 |
| fungi | so be on the lookout for that i guess | 12:47 |
| sean-k-mooney | the issue with lfx insighte crrently is while they have started to add minimal gerrit metrics we dotn actully have any review stats currently | 12:47 |
| sean-k-mooney | or alsmost none | 12:48 |
| sean-k-mooney | they added mean time between first review and time to merge | 12:48 |
| sean-k-mooney | but we can actully see review distibutiosn or volume or similar | 12:48 |
| sean-k-mooney | so we can judge review engagement or capsity ectra | 12:48 |
| sean-k-mooney | the cncf built a seperate devstats tool that hey use instead | 12:49 |
| fungi | yeah, some of the more aggregate numbers are coming from requests the community managers made in order to be able to continue pulling data for this specific effort, but we're also passing along requests for the things the broader community was relying on bitergia for | 12:49 |
| sean-k-mooney | which is just graphaa https://all.devstats.cncf.io/d/85/project-country-statistics https://github.com/cncf/devstats | 12:50 |
| fungi | the lfx team is really eager to make the insights platform work for community needs rather than just lf internal/staff needs, in part to make what cncf resorted to less necessary | 12:50 |
| sean-k-mooney | ya so in the last week or 2 the bitergia and statalitic site i belive ware not both offline | 12:52 |
| sean-k-mooney | so without creatign our own stats tool we are now relient on what lfx provieds | 12:52 |
| fungi | indeed, openinfra's annual contract with bitergia ran out and wasn't renewed, with the idea that the lfx developers are going to try to continue filling in the gaps there | 12:53 |
| sean-k-mooney | we are a bit offtopic i guess was there anythign else you wanted to highlight form the survay | 12:53 |
| dviroel | thanks for sharing the info fungi, i will take a more deep look into that afterwards | 12:53 |
| dviroel | if that's all that you plan to share | 12:54 |
| fungi | i didn't have anything else specific no, but am happy to answer more questions either now or next week after you've had time to mull this over | 12:54 |
| dviroel | we can move on then | 12:54 |
| dviroel | thanks fungi o/ | 12:54 |
| fungi | yw | 12:54 |
| dviroel | #topic Reviews | 12:54 |
| dviroel | ok so I would like to request for everybody to update our status etherpad | 12:55 |
| dviroel | #link https://etherpad.opendev.org/p/watcher-2026.1-status | 12:55 |
| dviroel | so we can track all changes that we want to merge in the following weeks | 12:55 |
| dviroel | I already added some, but i will be updating in the following hours | 12:55 |
| dviroel | any specific review that needs attention? | 12:56 |
| dviroel | ok then, lets revisit the etherpad next week one by one then | 12:56 |
| dviroel | we don't have too much time today :) | 12:56 |
| dviroel | next | 12:56 |
| dviroel | #topic Bugs | 12:57 |
| dviroel | One bug that I found that is missing triage | 12:57 |
| dviroel | #link https://bugs.launchpad.net/watcher/+bug/2131043 | 12:57 |
| dviroel | amoralej_ already answered this LP | 12:57 |
| amoralej_ | Actually, i think it's triaged | 12:57 |
| chandankumar | Add skip action feature with microversion support | https://review.opendev.org/c/openstack/watcher-dashboard/+/958209 is pending from long time, I have got a test coverage here also https://review.opendev.org/c/openstack/watcher-dashboard/+/976594 , Please have a look when you get time, thank you! | 12:57 |
| dviroel | for watcher is missing status and importance | 12:58 |
| dviroel | but is this a bug? | 12:58 |
| sean-k-mooney | not entirly | 12:59 |
| dviroel | isn't the expected behavior when you don't have notifications enabled? | 12:59 |
| sean-k-mooney | docs bug perhaps | 12:59 |
| amoralej_ | that's the point, so from one side a patch to the doc provided guidance between interval and period | 12:59 |
| amoralej_ | the doc patch is merged | 12:59 |
| sean-k-mooney | this is what notificaiton are inteded to fix | 12:59 |
| amoralej_ | said that, we may also make the code more resilient for these cases | 13:00 |
| sean-k-mooney | did we confirm if they had notificaiton enabled in the charm installer | 13:00 |
| sean-k-mooney | ya there is also a seond factor | 13:00 |
| sean-k-mooney | which is there is latency for the data souce to have data on the new node | 13:00 |
| sean-k-mooney | i.e. for promethous we scrape at a given interval | 13:00 |
| sean-k-mooney | gnocci is a push model so that is less of an issue | 13:00 |
| amoralej_ | no, notifications wasn't enabled | 13:00 |
| dviroel | so maybe there are still place for more doc improvements here? | 13:01 |
| amoralej_ | at least in the initial reporter | 13:01 |
| sean-k-mooney | ack so in the charm installer that is somethign it shoudl supprot and that the user shoudl enable | 13:01 |
| sean-k-mooney | i think we shoudl clsoe it as not a bug if the doc update is merged | 13:02 |
| amoralej_ | also in the charm https://review.opendev.org/c/openstack/charm-watcher/+/973822/3/src/config.yaml note "This charm does not support notification-based cluster model updates." | 13:02 |
| sean-k-mooney | but we shoudl also reply to them and tell them about the imporantce of notifications | 13:02 |
| sean-k-mooney | right my perspecitve is the collerctors are for perodic healing and the notriifcaion are the primary way the model shoudl be updated | 13:02 |
| dviroel | that's my opinion too, for watcher is not a bug | 13:03 |
| sean-k-mooney | it woudl be good to make that clear in the docs if other agree | 13:03 |
| jgilaber | +1 | 13:03 |
| amoralej_ | +1 | 13:03 |
| * dviroel we are out of time | 13:03 | |
| dviroel | should we use this LP to track doc update or set as Not a bug? | 13:04 |
| dviroel | ok, we are out of time | 13:05 |
| dviroel | #topic volunteers to chair next meeting | 13:05 |
| amoralej_ | We can close this to make it clear is expected and create a new one for doc imo | 13:05 |
| dviroel | someone wants to chair the next one? | 13:05 |
| dviroel | amoralej_: yeah, that would be better imho too | 13:05 |
| dviroel | I will do the LP work after this meeting | 13:06 |
| jgilaber | I can chair the next meeting | 13:06 |
| * dviroel was writting the same | 13:06 | |
| dviroel | thanks jgilaber | 13:06 |
| dviroel | let's wrap up for today | 13:06 |
| dviroel | we will meet again next week | 13:06 |
| dviroel | thank you all for participating | 13:06 |
| dviroel | #endmeeting | 13:07 |
| opendevmeet | Meeting ended Thu Feb 12 13:07:02 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:07 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-02-12-12.00.html | 13:07 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-02-12-12.00.txt | 13:07 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-02-12-12.00.log.html | 13:07 |
| amoralej_ | thanks dviroel for chairing! | 13:07 |
| amoralej_ | I'd like to ask for reviews in jgilaber patch https://review.opendev.org/c/openstack/watcher/+/963857 i hit that while testing the skip for volume_migrate and i think it's an important one | 13:08 |
| dviroel | amoralej_: ack, this one I was planning to dig more to see if we are not introducing any other issue while trying to fix the current one, that's why i still didn't approve it yet | 13:10 |
| dviroel | but it also solves an issue that we have | 13:10 |
| dviroel | so I will try to get back to this patch | 13:11 |
| sean-k-mooney | amoralej_: i left some comment on https://bugs.launchpad.net/watcher/+bug/2131043 by the way we likely should warn if notficaion are disabled and the interval of the audit is less the the collector interval | 13:12 |
| sean-k-mooney | and sure ill take a look at https://review.opendev.org/c/openstack/watcher/+/963857 now | 13:13 |
| sean-k-mooney | on its https://bugs.launchpad.net/watcher/+bug/2127485 | 13:13 |
| amoralej_ | warn in the logs? | 13:14 |
| amoralej_ | thanks sean-k-mooney and dviroel | 13:14 |
| sean-k-mooney | amoralej_: yes it would be good to tell the operator that there is a missmatch betwen there audit interval and the collecorts i think | 13:15 |
| sean-k-mooney | perhaps that overkill but it might help | 13:15 |
| sean-k-mooney | but only if notifciaiotn are not used | 13:15 |
| amoralej_ | yes, we can do that when a new audit is created, but that's not visible for the user creating the audit, i'm not sure it will help much | 13:17 |
| amoralej_ | but at least to troubleshoot in case the problem is reported | 13:17 |
| sean-k-mooney | well we cant reprot it to the end user because that woudl be leakign private info about the config to the user | 13:37 |
| sean-k-mooney | and while they may be an admin today we shoudl not asume that going forward | 13:37 |
| opendevreview | Merged openstack/watcher stable/2025.2: Support zone migration audit without compute_nodes https://review.opendev.org/c/openstack/watcher/+/961442 | 13:38 |
| sean-k-mooney | my thinking was operators that are runign it could at least know when there is an audit that runs faster then the model updates adn coudl reivew that audit witht eh end user or consier updateing there config | 13:38 |
| opendevreview | Merged openstack/watcher stable/2025.2: Improve unit tests for zone migration strategy https://review.opendev.org/c/openstack/watcher/+/961443 | 13:38 |
| sean-k-mooney | but its not required | 13:38 |
| sean-k-mooney | it was just an idea | 13:38 |
| opendevreview | Merged openstack/watcher stable/2025.2: Add unit tests for instance and volume not found in model https://review.opendev.org/c/openstack/watcher/+/961632 | 14:13 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Fix check for volume type in cinder helper migrate https://review.opendev.org/c/openstack/watcher/+/963857 | 14:37 |
| *** amoralej_ is now known as amoralej | 15:01 | |
| opendevreview | Merged openstack/watcher stable/2025.2: Fix zone migration instance not found issue https://review.opendev.org/c/openstack/watcher/+/961635 | 16:38 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Use wrapper classes for novaclient objects https://review.opendev.org/c/openstack/watcher/+/972913 | 16:45 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Prepare to use openstacksdk instead of novaclient https://review.opendev.org/c/openstack/watcher/+/974710 | 16:45 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Complete migration from novaclient to openstacksdk https://review.opendev.org/c/openstack/watcher/+/974924 | 16:45 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove usage of novaclient from Watcher https://review.opendev.org/c/openstack/watcher/+/974925 | 16:45 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove nova_helper retries for openstacksdk params https://review.opendev.org/c/openstack/watcher/+/975498 | 16:45 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Use wrapper classes for novaclient objects https://review.opendev.org/c/openstack/watcher/+/972913 | 16:52 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Prepare to use openstacksdk instead of novaclient https://review.opendev.org/c/openstack/watcher/+/974710 | 16:52 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Complete migration from novaclient to openstacksdk https://review.opendev.org/c/openstack/watcher/+/974924 | 16:52 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove usage of novaclient from Watcher https://review.opendev.org/c/openstack/watcher/+/974925 | 16:52 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove nova_helper retries for openstacksdk params https://review.opendev.org/c/openstack/watcher/+/975498 | 16:52 |
| opendevreview | Merged openstack/watcher stable/2025.2: Fix zone migration to accept dst_pool or dst_type https://review.opendev.org/c/openstack/watcher/+/968817 | 16:54 |
| jgilaber | amoralej, dviroel, sean-k-mooney thanks for the reviews on ^^ I know it was not an easy one. I've updated the chain without the changes to the action/strategies | 16:54 |
| sean-k-mooney | ack ill loop back to those tomorrow or monday | 16:55 |
| dviroel | jgilaber: ack, thanks | 17:08 |
| jgilaber | btw the last backport to 2025.2 landed a few minutes ago, tomorrow I'll prepare the release | 17:19 |
| dviroel | +1 | 17:22 |
| sean-k-mooney | cool. we shoudl proably do a round of stable reivew for older branches too now that those have landed but not this week :) | 17:26 |
| opendevreview | Douglas Viroel proposed openstack/watcher master: Enable Applier parallel engine in native thread mode https://review.opendev.org/c/openstack/watcher/+/975522 | 21:32 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!