| opendevreview | Joan Gilabert proposed openstack/watcher master: Prepare to use openstacksdk instead of novaclient https://review.opendev.org/c/openstack/watcher/+/974710 | 08:52 |
|---|---|---|
| opendevreview | Joan Gilabert proposed openstack/watcher master: Complete migration from novaclient to openstacksdk https://review.opendev.org/c/openstack/watcher/+/974924 | 08:52 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove usage of novaclient from Watcher https://review.opendev.org/c/openstack/watcher/+/974925 | 08:52 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove nova_helper retries for openstacksdk params https://review.opendev.org/c/openstack/watcher/+/975498 | 08:52 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: [DNM] Test openstacksdk changes without [nova] section https://review.opendev.org/c/openstack/watcher/+/977292 | 08:52 |
| opendevreview | Marcin Wilk proposed openstack/watcher stable/2025.1: Add debug message to report calculated metric for workload_balance https://review.opendev.org/c/openstack/watcher/+/977299 | 09:43 |
| *** tkajinam_ is now known as tkajinam | 10:13 | |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove monasca datasource https://review.opendev.org/c/openstack/watcher/+/966786 | 11:13 |
| jgilaber | Hi all! Reminder that the Watcher IRC meeting will start in ~30 minutes. Feel free to add any topics to the agenda https://etherpad.opendev.org/p/openstack-watcher-irc-meeting | 11:33 |
| jgilaber | #startmeeting watcher | 12:00 |
| opendevmeet | Meeting started Thu Feb 19 12:00:44 2026 UTC and is due to finish in 60 minutes. The chair is jgilaber. 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 |
| jgilaber | hi all o/, who is around today? | 12:01 |
| dviroel | o/ | 12:01 |
| jgilaber | courtesy ping: amoralej sean-k-mooney chandankumar morenod rlandy | 12:01 |
| sean-k-mooney | o/ | 12:01 |
| chandankumar | o/ | 12:02 |
| fungi | ahoy! | 12:02 |
| amoralej_ | o/ | 12:02 |
| jgilaber | thanks for joining I think we can get started with the agend, feel free to add topics | 12:03 |
| jgilaber | #link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L36 | 12:03 |
| jgilaber | #topic Announcements | 12:03 |
| jgilaber | Gazpacho schedule, next week is feature freeze | 12:04 |
| jgilaber | I've added the list of in progress blueprints and features that we targeted for this cycle | 12:04 |
| jgilaber | a more complete list can be found in the status etherpad | 12:04 |
| dviroel | ++ | 12:04 |
| jgilaber | #link https://etherpad.opendev.org/p/watcher-2026.1-status | 12:05 |
| jgilaber | I'm not sure if we want to go over the list here, wdyt? | 12:05 |
| sean-k-mooney | the osprofiler work is for next cycle | 12:05 |
| jgilaber | that's true, the bluepring is not approved, my bad | 12:06 |
| dviroel | i think that we can keep cover the open blueprints | 12:06 |
| sean-k-mooney | but we can hopefully compelt ethe reset in the next few days | 12:06 |
| chandankumar | jgilaber, I think we also moved watcher-dashboard unit/integration testing to next cycle | 12:06 |
| dviroel | yes, both | 12:06 |
| jgilaber | ack, thanks | 12:06 |
| jgilaber | looks to me like we're in good shape | 12:06 |
| jgilaber | please consider prioritizing these reviews so we don't have to rush too much close to the deadline | 12:07 |
| sean-k-mooney | yes the sdk work is obvioulsy going to continue next cycle but we are makeing good progress there thanks jgilaber for working on that | 12:07 |
| jgilaber | any comments on any of the features? | 12:07 |
| amoralej_ | for the skip | 12:07 |
| jgilaber | yes, the primary goal was to move novaclient, I think we'll get that | 12:07 |
| jgilaber | go ahead amoralej_ | 12:07 |
| amoralej_ | I mean https://blueprints.launchpad.net/watcher/+spec/skip-actions-in-pre-condition | 12:07 |
| amoralej_ | there is https://review.opendev.org/c/openstack/watcher/+/976393 for volume_migrate | 12:08 |
| amoralej_ | and there is also pending resize | 12:08 |
| sean-k-mooney | ack i can add that to my list i think we can likely get that in in the next week or so | 12:08 |
| amoralej_ | i was waiting for the openstacksdk to be merged before sending the resize, but i can send my patch on top of the openstacksdk series | 12:08 |
| sean-k-mooney | ya that sound reasonable | 12:09 |
| amoralej_ | i don't want to add more dependencies to the openstacksdk work which is much more complex | 12:09 |
| jgilaber | I started reviewing the volume_migrate this morning | 12:09 |
| jgilaber | +1 to adding it on top, I think the openstacksdk patches are close now | 12:09 |
| amoralej_ | for the volume_migrate, other than the code aspect, about the conditions where i propose to skip | 12:10 |
| amoralej_ | have any commnet? | 12:10 |
| amoralej_ | - The volume does not exist | 12:10 |
| amoralej_ | - The destination_type does not exist (if specified) | 12:10 |
| amoralej_ | - The destination_node (pool) does not exist (if specified) | 12:10 |
| amoralej_ | - The migration_type is 'retype' and the destination_type is the same as the | 12:10 |
| amoralej_ | current volume type | 12:10 |
| amoralej_ | - The migration_type is 'migrate' and the destination_node is the same as the | 12:10 |
| amoralej_ | current volume host | 12:10 |
| amoralej_ | wdyt ? | 12:10 |
| sean-k-mooney | so some of those shoudl be rejected before we get to the audit execution time eventually | 12:11 |
| amoralej_ | those would skip, you think that any of those should fail instead? | 12:11 |
| sean-k-mooney | but i think overall that looks ok | 12:11 |
| jgilaber | the last two I think could be interpreted as a failure instead of skip | 12:11 |
| jgilaber | I could see either way | 12:11 |
| dviroel | amoralej_: going to review volume migrate, but it will be better if you can send the resize asap, on top of the openstacksdk, later we can just rebase it | 12:11 |
| amoralej_ | actually, for me the last two are more clear skip :) as it's requesting a state which is current | 12:11 |
| jgilaber | sorry I misread that | 12:11 |
| amoralej_ | i had more doubts about the destination type or pool do not exist | 12:12 |
| jgilaber | yes that is what I was thinking about | 12:12 |
| amoralej_ | yeah, i had doubts about that too | 12:12 |
| jgilaber | I read the commit message a bit before starting the meeting | 12:12 |
| sean-k-mooney | amoralej_: so all of the above are normlly thing thiat i owudl prefer to reject with a 400 in teh api when you define the audit | 12:12 |
| jgilaber | but I had not gotten to that point in the code to comment | 12:12 |
| sean-k-mooney | for now i think skiping the invalid actions is an ok compromise | 12:12 |
| amoralej_ | yes, but remember that things may change between audit execution and actionplan execution | 12:12 |
| amoralej_ | so we will always need to check in actions too | 12:13 |
| sean-k-mooney | we know migrate to the the same pool is invalid at the cinder level so we shoud lnto accpate that request | 12:13 |
| sean-k-mooney | yep | 12:13 |
| sean-k-mooney | that why im ok with skiping the action in that case | 12:13 |
| amoralej_ | yep | 12:13 |
| sean-k-mooney | just down the road i woudl either want to not generate the action at all | 12:13 |
| jgilaber | to clarify, I'm ok with skipping for the list that you pasted here | 12:13 |
| sean-k-mooney | i.e. filter earler or catch it at audit defintion time | 12:13 |
| amoralej_ | ok, anyway, don't want to invest much time on this in the mtg as i guess there is more relevant stuff, feel free to comment there | 12:14 |
| sean-k-mooney | i tihnk in the scope fo this cycle what you proposed above is ok provided we docuemnet it | 12:14 |
| amoralej_ | yeah, i agree it'd be good to validate at audit creation too | 12:14 |
| jgilaber | ok, any other comments on the open features? | 12:15 |
| sean-k-mooney | related | 12:15 |
| sean-k-mooney | chandan i belive you have the ui change to supprot skip in horizon | 12:15 |
| sean-k-mooney | what is the current state fo that work | 12:15 |
| sean-k-mooney | is it blocked by the pkg_reosuces issues or have enough of the xstatic packages been promoted that our plugin and dashboard jobs are passing again? | 12:16 |
| chandankumar | sean-k-mooney, yes, it needs one more revision | 12:16 |
| amoralej_ | I tested yesterday https://review.opendev.org/c/openstack/watcher-dashboard/+/958209 and leave a couple of comments | 12:16 |
| chandankumar | I am on it | 12:16 |
| amoralej_ | great | 12:16 |
| chandankumar | job is working fine in ci | 12:17 |
| sean-k-mooney | ack ok lets do a review after FF and see where we got to with these items. nothing elser form me on this so i think the floor is proably fungi's? | 12:17 |
| jgilaber | if there is nothing else we can move to the next topci from fungi | 12:17 |
| jgilaber | #topic Bridging the Gap Flamingo Cycle Retrospective followup | 12:17 |
| fungi | this effort started with representatives from member organizations sharing frustrations with, primarily, their employees' experiences trying to contribute patches in various openstack projects | 12:18 |
| fungi | investigating these reports on a case-by-case basis, foundation staff concluded most misunderstandings were due to mismatched expectations arising from incomplete communication or silence (and not necessarily on the part of the maintainers) | 12:18 |
| fungi | what we've observed from successful exchanges in some projects is that increasing communication effectiveness ultimately leads to improved efficiency and time savings for all parties involved; some examples include: | 12:18 |
| fungi | documenting review priorities and the prioritization process, as well as publicizing it more (e.g. with pointers in review comments), so that change owners know the priority for their own work and how to get involved in that decision | 12:18 |
| fungi | proactively communicating reviewer availability, changes in availability, and explicit handoff to other reviewers, so that change owners know how long they might be waiting (and encouraging them to communicate their own availability) | 12:18 |
| fungi | overall clearer communications with change owners, for example avoiding heavy reliance on acronyms and team-specific jargon, since english is not the primary language for a majority of our community and their familiarity with it varies | 12:18 |
| fungi | to this end, i and other community managers on the foundation staff are working on putting together some materials that we hope teams will find useful, and will collaborate with us to help improve and expand further | 12:18 |
| fungi | one thing we want to try is cut-and-paste review response templates for common situations; the vulnerability management team has used similar techniques for bug triage and assembling advisories, and they've found it saves a lot of time | 12:18 |
| fungi | another is assembling contributor and reviewer checklists to help avoid common pitfalls and anti-patterns, based on all of the earlier focus group feedback and brainstorming sessions we held with the community in 2024 | 12:18 |
| fungi | something else we want to try is collaborating to produce case studies with companies who have been investing in project maintenance work and whose employees have a track record of successful contribution patterns | 12:19 |
| fungi | we also plan to continue identifying additional tactics and strategies that teams have positive experiences with, to see if there's a way they can be generalized for adoption by other teams facing similar challenges | 12:19 |
| fungi | if anybody has follow-up thoughts or questions on any of the above, as well as for the survey and metrics analysis from last week now that you've had time to mull it over, i'm happy to answer questions and entertain feedback here | 12:19 |
| fungi | (or in irc after the meeting, or on the openstack-discuss mailing list, or even directly/in private for that matter) | 12:19 |
| fungi | and if not, i yield back the podium ;) | 12:20 |
| sean-k-mooney | one thing i have been trying to push is more automated tool feedback. i.e by adopting ruff/pre-commit and by adding ai code review. so that all continbutors get feed back earler if possibel | 12:20 |
| jgilaber | thanks fungi there is some good advice there | 12:20 |
| fungi | yeah, i'm eager to see where your llm-driven code review experiments end up, sean-k-mooney | 12:21 |
| sean-k-mooney | as we have all got buiser withmore hats and less people i feel tool assited review is very imporant | 12:21 |
| sean-k-mooney | fungi: i need to invest more tiem in makign it more widely useful but it has been finding bugs | 12:22 |
| sean-k-mooney | it going to be a topic i want to dicuss at the ptg | 12:22 |
| fungi | i've not used llm reviews myself, though i've seen some especially useless ones on github projects from microsoft's free tier of copilot | 12:22 |
| sean-k-mooney | basiclly i want to see how the rest of the watcher team have found it | 12:22 |
| jgilaber | I've been positively surprised by the output | 12:22 |
| sean-k-mooney | since im obviously biased by creating it :) | 12:22 |
| jgilaber | it often catches issues and it does not hallucinate too much | 12:23 |
| sean-k-mooney | ^ that im plannitn to improve in the next few weeks. i have a collection of impovement planed | 12:23 |
| amoralej_ | i guess it will be a topic for ptg discussion | 12:23 |
| dviroel | yeah, I'm starting to look more at its outputs since it is adding valuable comments and finding lots of issues | 12:23 |
| sean-k-mooney | well we can disucss it in other forms as well | 12:23 |
| amoralej_ | also, it'd be great if we could reduce out-of-scope comments | 12:23 |
| sean-k-mooney | yep that high on my list | 12:24 |
| sean-k-mooney | i realise my comemnt treshold is curently at 0.6 instead of 0.8 and i actully watn to hold lower severity comment to a hihger treshold | 12:24 |
| sean-k-mooney | i.e 0.8 for critical and 0.95 for suggestions for inlien comments | 12:25 |
| sean-k-mooney | all obsrervations will still be in the html report | 12:25 |
| fungi | right, our meatspace reviewers mostly understand that commenting on style outside the lines being changed in the diff is poor form, and that commenting outside the lines changed is generally not helpful except when it's pointing out something relied on/used by the lines being changed/added/removed | 12:25 |
| sean-k-mooney | but i want to increase the signal to noise ratio in the reviews | 12:25 |
| sean-k-mooney | fungi: yep those are all conventions im plannign to teach it | 12:26 |
| sean-k-mooney | and this is the feedback i want form the team before sharing it more widely | 12:26 |
| fungi | makes sense, sounds like awesome progress | 12:26 |
| jgilaber | ok, any other comments on this topic before moving to reviews? | 12:26 |
| fungi | thanks everyone! | 12:27 |
| jgilaber | thanks fungi! | 12:27 |
| jgilaber | #topic Reviews | 12:27 |
| jgilaber | we only have one today, from dviroel | 12:27 |
| jgilaber | #link https://review.opendev.org/c/openstack/watcher/+/975916 | 12:27 |
| jgilaber | dviroel, did you want to point out anything? | 12:28 |
| dviroel | this one was sent to cover a topic from last ptg | 12:28 |
| sean-k-mooney | approved :) | 12:28 |
| dviroel | I think that is a good to merge | 12:28 |
| dviroel | oh nice :) | 12:28 |
| sean-k-mooney | il like -1+18 reviews | 12:28 |
| sean-k-mooney | makes it really simple to review | 12:28 |
| jgilaber | quick and easy, let's triage some bugs then | 12:29 |
| jgilaber | #topic Bugs | 12:29 |
| jgilaber | we have a few new bugs | 12:29 |
| jgilaber | #link https://bugs.launchpad.net/watcher/+bug/2141996 | 12:29 |
| amoralej_ | yeah, i added some | 12:29 |
| amoralej_ | some related to scalability, performance | 12:30 |
| jgilaber | this first one seems like a nice improvement, but not critical | 12:30 |
| amoralej_ | about that one, it's a simple one, we are printing up to three times the model on an audit execution, wasting time and cpu | 12:30 |
| sean-k-mooney | amoralej_: i kind of agree we either rely on 1 or remove it and alwasy do it before and after execute but not in the stragy | 12:31 |
| amoralej_ | that can be easily cleaned to leave one print only. we can also optimize how we convert into text, but that's a different | 12:31 |
| sean-k-mooney | as in make it something the descion envine does | 12:31 |
| amoralej_ | so, my idea was to print it when the model for that particular audit execution is created | 12:32 |
| sean-k-mooney | if we proceed with the teiring/stackign feature | 12:32 |
| amoralej_ | actually, we already have that | 12:32 |
| sean-k-mooney | we may need to print it between stages as well | 12:32 |
| sean-k-mooney | given we are disucssing mutating it | 12:33 |
| dviroel | indeed | 12:33 |
| amoralej_ | https://github.com/openstack/watcher/blob/bf6c7e2e27b8c48941652e63d8f65e23e6f6a146/watcher/decision_engine/model/collector/base.py#L184 | 12:33 |
| amoralej_ | tht's the one i want to keep | 12:33 |
| sean-k-mooney | so _pre_execute and post_execute feel more natual to me | 12:33 |
| sean-k-mooney | that way i orgianlly saide remvoe it form get_latest_cluster_data_model | 12:33 |
| amoralej_ | ^ is executed on the first time the model is accessed from the strategy | 12:34 |
| sean-k-mooney | but ya thats the one tha feels the lesst natural to me | 12:34 |
| amoralej_ | why ? | 12:34 |
| amoralej_ | i mean, note that's copying the model and creating a new one | 12:34 |
| sean-k-mooney | becuase i woudl not expect gettign the model to have the side effect of printing it | 12:35 |
| amoralej_ | it's not like a simple read mehtod | 12:35 |
| sean-k-mooney | right aht also feels a bit incorect based on the name | 12:35 |
| dviroel | and this may not be the model that the strategy will be using, in case we provide a scope? | 12:35 |
| amoralej_ | that's right | 12:36 |
| amoralej_ | that's a good reason to remove that debug tbh | 12:36 |
| sean-k-mooney | and keep https://github.com/openstack/watcher/blob/bf6c7e2e27b8c48941652e63d8f65e23e6f6a146/watcher/decision_engine/strategy/strategies/base.py#L253 | 12:37 |
| sean-k-mooney | right so we only print the one it actully used | 12:37 |
| amoralej_ | yeah | 12:37 |
| amoralej_ | you convinced me :) | 12:37 |
| sean-k-mooney | i thikn for now if we remove it form post execute and remove it form the collector fucntion that woudl be the best path forward | 12:38 |
| jgilaber | ok, so what about the importance? low/medium? | 12:38 |
| dviroel | yeah | 12:38 |
| sean-k-mooney | can we rename get_latest_cluster_data_model as well | 12:38 |
| sean-k-mooney | get_latest_cluster_data_model -> copy_latest_cluster_data_model | 12:38 |
| sean-k-mooney | i would say low | 12:38 |
| amoralej_ | actually, the model as derivated from networkx.Digraph provides already a copy method | 12:38 |
| amoralej_ | maybe that's all we need | 12:39 |
| sean-k-mooney | its anoying at debug level but not not operationaly problematic beyond that | 12:39 |
| amoralej_ | yeah | 12:39 |
| sean-k-mooney | amoralej_: sound like somethign that would be good to include in the clean up | 12:39 |
| sean-k-mooney | my main concuer is that we need a deepcopy | 12:39 |
| amoralej_ | anyway, i'll go with that idea of keep only in _pre_execute | 12:40 |
| sean-k-mooney | so we woudl have to validate if networkx.Digraph does that or not | 12:40 |
| amoralej_ | according to doc at least, i'd say so | 12:40 |
| amoralej_ | but yeah, it may be good to compare the implementations | 12:40 |
| dviroel | +1 | 12:41 |
| jgilaber | marking the bug as low, any other comments for this one? | 12:41 |
| amoralej_ | it's low, but not super low, imo :) note in a big environment, a host_migrate strategy took 25 seconds | 12:42 |
| amoralej_ | 24 were from the 3 prints :) | 12:42 |
| amoralej_ | so cleaning that should reduce to ~8sec | 12:42 |
| amoralej_ | but yeah, not the worst case we have | 12:43 |
| jgilaber | that will be a nice improvement | 12:43 |
| dviroel | low is fine | 12:43 |
| jgilaber | moving to the second bug | 12:43 |
| jgilaber | #link https://bugs.launchpad.net/watcher/+bug/2141671 | 12:43 |
| jgilaber | this is a folloup from last weeks meeting discussion, right dviroel? | 12:44 |
| dviroel | yes correct | 12:44 |
| dviroel | follow up from https://bugs.launchpad.net/watcher/+bug/2131043 | 12:44 |
| jgilaber | so similarly, also low? | 12:44 |
| dviroel | that I set to invalid, based on our discussions | 12:45 |
| dviroel | yeah so it is a doc improvement | 12:45 |
| dviroel | i would set as low | 12:45 |
| dviroel | but still relevant to propose a patch | 12:45 |
| jgilaber | +1, any other comment on this one? | 12:45 |
| sean-k-mooney | not form me | 12:46 |
| sean-k-mooney | i left my comments in the bug itself | 12:46 |
| jgilaber | ack, thanks sean-k-mooney, moving to the third bug in the list | 12:46 |
| jgilaber | #link https://bugs.launchpad.net/watcher/+bug/2141937 | 12:46 |
| amoralej_ | after doing some tets with zone_migration and observe memory consumption | 12:47 |
| amoralej_ | https://launchpadlibrarian.net/847955712/Memory_zone_migration.png | 12:47 |
| amoralej_ | looks like zone_migration execution increases memory and seems some memory is not garbage collected | 12:48 |
| amoralej_ | I couldn't find where is that memory going, but i think there is some issue there | 12:48 |
| sean-k-mooney | we likely have a dagneling refernce somewhere or a cycle | 12:48 |
| sean-k-mooney | we could add an explcit call to the python garbage collector at the end fo every action plan execution | 12:49 |
| amoralej_ | i think we should also work on bugs.launchpad.net/watcher/+bug/2119957 | 12:49 |
| sean-k-mooney | that can help with the cleanup of self referencial data stuctures | 12:49 |
| sean-k-mooney | https://bugs.launchpad.net/watcher/+bug/2141937 i think sould be high | 12:50 |
| sean-k-mooney | i also agree that working on https://bugs.launchpad.net/watcher/+bug/2119957 makes sense but i think medium is also approprate | 12:50 |
| amoralej_ | ack | 12:51 |
| sean-k-mooney | im not saying anything about the ordering here | 12:51 |
| sean-k-mooney | just that the potical memory leak is more operationally impactful | 12:51 |
| dviroel | yeah | 12:51 |
| amoralej_ | i'm afraid that the leak may be related to connections, etc... and potentially those calls? | 12:52 |
| amoralej_ | just a guess, tbh | 12:52 |
| jgilaber | +1, given that zone migration is the only strategy making direct calls to APIs it's possible that solving https://bugs.launchpad.net/watcher/+bug/2119957 could fix https://bugs.launchpad.net/watcher/+bug/2141937 | 12:52 |
| amoralej_ | yeah, that was my point, it's something pretty unique for that strategy | 12:52 |
| sean-k-mooney | its possible but i dont think that is likely | 12:52 |
| sean-k-mooney | but if its the only stragey where this is happeneing | 12:53 |
| sean-k-mooney | then its worth a shot | 12:53 |
| jgilaber | but https://bugs.launchpad.net/watcher/+bug/2141937 does seem potentially more dangerous so I agree with marking it high | 12:53 |
| amoralej_ | yeah, sure | 12:53 |
| sean-k-mooney | we need to fix both eventurlly in any case | 12:53 |
| jgilaber | +1, marking it as high and moving to the next bug if there are no further comments | 12:54 |
| jgilaber | #link https://bugs.launchpad.net/watcher/+bug/2141939 | 12:54 |
| sean-k-mooney | medium. | 12:55 |
| amoralej_ | as stated in the subject, vm_workloads_consolidation doesn't finish in big environment in more than 1 hr | 12:55 |
| amoralej_ | medium lgtm | 12:56 |
| sean-k-mooney | im saying medium because we can document this as a know limiation, and advices the node_workload_consolition as a workaround | 12:56 |
| sean-k-mooney | i think we can optimise the algorthim to scale in the future | 12:56 |
| sean-k-mooney | and should | 12:56 |
| jgilaber | ok, looks like we are in agreement here, setting it as medium | 12:56 |
| amoralej_ | I'd like to have some limit about when it starts finding issues, but i don0t have it | 12:56 |
| sean-k-mooney | but btu we can also use scop or simialr to help here | 12:57 |
| amoralej_ | we could document that, right | 12:57 |
| sean-k-mooney | yep we could | 12:57 |
| amoralej_ | So, similar for https://bugs.launchpad.net/watcher/+bug/2141951 | 12:58 |
| jgilaber | ok, so we've got two minutes, I think we can leave it here and move the two missing bugs for next week | 12:58 |
| sean-k-mooney | by the way we shoudl start using tags o nthe bugs like perf | 12:58 |
| sean-k-mooney | so we can track the types of bugs we have a littel better | 12:58 |
| amoralej_ | i like that | 12:58 |
| jgilaber | that sounds like a good idea | 12:59 |
| sean-k-mooney | lets loop back to that next week | 12:59 |
| jgilaber | I'll add it to the agenda for next week | 12:59 |
| jgilaber | last topic | 12:59 |
| jgilaber | #topic Volunteers to chair next meeting | 12:59 |
| jgilaber | any volunteer? | 13:00 |
| amoralej_ | i can take it | 13:00 |
| jgilaber | thanks amoralej_ | 13:00 |
| dviroel | nice, thanks amoralej_ | 13:00 |
| jgilaber | that's all for today, thanks everyone! | 13:00 |
| jgilaber | #endmeeting | 13:00 |
| opendevmeet | Meeting ended Thu Feb 19 13:00:40 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-02-19-12.00.html | 13:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-02-19-12.00.txt | 13:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-02-19-12.00.log.html | 13:00 |
| dviroel | thanks jgilaber++ | 13:00 |
| amoralej_ | thanks jgilaber ! | 13:01 |
| chandankumar | thanks jgilaber ! | 13:02 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Skip change_nova_service_state actions in pre_condition phase https://review.opendev.org/c/openstack/watcher/+/977340 | 16:33 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Skip volume_migrate actions in pre_condition phase https://review.opendev.org/c/openstack/watcher/+/976393 | 16:40 |
| opendevreview | Merged openstack/watcher master: Enable Applier parallel engine in native thread mode https://review.opendev.org/c/openstack/watcher/+/975522 | 17:28 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Complete migration from novaclient to openstacksdk https://review.opendev.org/c/openstack/watcher/+/974924 | 18:07 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove usage of novaclient from Watcher https://review.opendev.org/c/openstack/watcher/+/974925 | 18:07 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove nova_helper retries for openstacksdk params https://review.opendev.org/c/openstack/watcher/+/975498 | 18:07 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: [DNM] Test openstacksdk changes without [nova] section https://review.opendev.org/c/openstack/watcher/+/977292 | 18:07 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Complete migration from novaclient to openstacksdk https://review.opendev.org/c/openstack/watcher/+/974924 | 18:21 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove usage of novaclient from Watcher https://review.opendev.org/c/openstack/watcher/+/974925 | 18:21 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove nova_helper retries for openstacksdk params https://review.opendev.org/c/openstack/watcher/+/975498 | 18:21 |
| opendevreview | sean mooney proposed openstack/watcher master: Add retry_on_deadlock decorators to missing database methods https://review.opendev.org/c/openstack/watcher/+/976293 | 18:53 |
| opendevreview | sean mooney proposed openstack/watcher master: Add regression test for retry_on_deadlock decorator https://review.opendev.org/c/openstack/watcher/+/977248 | 18:53 |
| opendevreview | Merged openstack/watcher master: Remove monasca datasource https://review.opendev.org/c/openstack/watcher/+/966786 | 21:27 |
| opendevreview | Merged openstack/watcher master: Deprecate rollback_when_actionplan_failed configuration https://review.opendev.org/c/openstack/watcher/+/975916 | 23:51 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
