| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Playwright Django52 job https://review.opendev.org/c/openstack/watcher-dashboard/+/992582 | 02:56 |
|---|---|---|
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Add Playwright-based E2E testing framework https://review.opendev.org/c/openstack/watcher-dashboard/+/970353 | 04:03 |
| 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 | 04:09 |
| 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 | 04:12 |
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Playwright Django52 job https://review.opendev.org/c/openstack/watcher-dashboard/+/992582 | 04:13 |
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Add Playwright-based E2E testing framework https://review.opendev.org/c/openstack/watcher-dashboard/+/970353 | 05:35 |
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Add Playwright-based E2E testing framework https://review.opendev.org/c/openstack/watcher-dashboard/+/970353 | 06:48 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Remove Nova API calls from zone_migration strategy https://review.opendev.org/c/openstack/watcher/+/988284 | 07:45 |
| 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 | 07:51 |
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Add Playwright integration test job for Django 5.2 https://review.opendev.org/c/openstack/watcher-dashboard/+/992582 | 07:56 |
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Add Playwright integration test job for Django 5.2 https://review.opendev.org/c/openstack/watcher-dashboard/+/992582 | 07:56 |
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Add Playwright-based E2E testing framework https://review.opendev.org/c/openstack/watcher-dashboard/+/970353 | 08:01 |
| 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 | 08:01 |
| 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:02 |
| 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:25 |
| opendevreview | chandan kumar proposed openstack/watcher-dashboard master: Add Playwright integration test job for Django 5.2 https://review.opendev.org/c/openstack/watcher-dashboard/+/992582 | 11:10 |
| opendevreview | Winicius Allan Bezerra da Silva proposed openstack/watcher-specs master: [WIP] Add spec for Preemptible Instances feature https://review.opendev.org/c/openstack/watcher-specs/+/987171 | 11:17 |
| dviroel | hi all - watcher weekly meeting will start in 10min - feel free to add topic to today's agenda: | 11:50 |
| dviroel | https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L32 | 11:50 |
| dviroel | #startmeeting watcher | 12:01 |
| opendevmeet | Meeting started Thu Jun 11 12:01:10 2026 UTC and is due to finish in 60 minutes. The chair is dviroel. Information about MeetBot at http://wiki.debian.org/MeetBot. | 12:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 12:01 |
| opendevmeet | The meeting name has been set to 'watcher' | 12:01 |
| * dviroel 1 min late :) | 12:01 | |
| dviroel | o/ hi all | 12:01 |
| winiciusallan[m] | o/ | 12:01 |
| morenod | o/ | 12:01 |
| jgilaber | o/ | 12:02 |
| chandankumar | o/ | 12:02 |
| dviroel | courtesy ping: amoralej sean-k-mooney rlandy | 12:02 |
| rlandy | o/ | 12:02 |
| amoralej | o/ | 12:02 |
| dviroel | thanks for joining o/ | 12:02 |
| dviroel | let's start with today's meeting agenda | 12:03 |
| dviroel | #link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L32 (Meeting agenda) | 12:03 |
| dviroel | as usual, feel free to add your own topics to the agenda | 12:03 |
| dviroel | note that there is a topic to place your changes that requires attention from reviewers | 12:03 |
| dviroel | we also have a topic for bugs, if you want to discuss any | 12:03 |
| dviroel | lets start with the first one... | 12:03 |
| dviroel | #topic Preemptible Instances Spec | 12:04 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher-specs/+/987171 | 12:04 |
| dviroel | winiciusallan[m]: thanks for adding the topic | 12:04 |
| dviroel | want to share latest changes made to the spec? | 12:04 |
| sean-k-mooney | o/ | 12:04 |
| dviroel | some of us already started reviewing it | 12:04 |
| dviroel | but it seems that winiciusallan[m] added more content recently | 12:05 |
| winiciusallan[m] | yeah, thank you doug | 12:05 |
| winiciusallan[m] | hi all, sorry for not attending to the last meeting | 12:05 |
| winiciusallan[m] | i was back and forthing trying to define a concrete strategy | 12:06 |
| winiciusallan[m] | i believe i got something now. thank you all for all the feedbacks | 12:06 |
| winiciusallan[m] | basically what I want to achieve is to guarantee a % of free allocated resources | 12:07 |
| winiciusallan[m] | to guarantee this, we preempt the so-called preemptible instnaces | 12:07 |
| winiciusallan[m] | I put more details in the spec, but the idea here is a provider can utilize their spare capacity with preemptible instances, but also control the on-demand pool by guaranteeing this amount of resource | 12:08 |
| winiciusallan[m] | this percentage will be set via input_parameter | 12:08 |
| amoralej | I was reviewing it right before the meeting, sorry i didn't reply yet | 12:08 |
| winiciusallan[m] | I'm proposing two ways of sorting and selecting candidates instances: by oldest or by utilization | 12:09 |
| winiciusallan[m] | also put more details in the spec, feedbacks are really appreciated | 12:09 |
| winiciusallan[m] | the policies to preempt instances didn't change, I just define better how this will be configured and a default value | 12:10 |
| winiciusallan[m] | I believe that's all from my side | 12:10 |
| amoralej | i have a global question, this would monitor resource allocations or usage? or both? | 12:10 |
| winiciusallan[m] | thats fine amoralej :) | 12:10 |
| dviroel | yeah, that's an important question | 12:11 |
| winiciusallan[m] | the optimization target would be regarding the allocated, but we will need to monitor the usage in case the operator would like to preempt based on the utilization | 12:11 |
| winiciusallan[m] | does it make sense? | 12:11 |
| amoralej | that sentence is confusing to me, sorry :) | 12:11 |
| dviroel | so the Goal is to free allocated resource, to give space for new instances? | 12:12 |
| winiciusallan[m] | yeah, that's right | 12:12 |
| sean-k-mooney | winiciusallan[m]: i think what amoralej is highlight is we currently have diffent stagees for the same goal | 12:12 |
| sean-k-mooney | and some use allcoation only | 12:12 |
| sean-k-mooney | other use allcoation+metics form teh data socue about utilisation | 12:12 |
| sean-k-mooney | winiciusallan[m]: so in the spec we shoudl descieb what you intend to use | 12:13 |
| sean-k-mooney | will it be configuabe | 12:13 |
| sean-k-mooney | will it be only the placment/flavor allcation ifno | 12:13 |
| sean-k-mooney | or will you take cpu utilsitiaon metics from teh data souce | 12:13 |
| sean-k-mooney | there is no wrong answe rhere realy | 12:13 |
| amoralej | let me give you a case. A cluster is 50% of CPUs allocation but 95% of usage (because of overcommitment of 4). Should the strategy stop instances? | 12:13 |
| sean-k-mooney | jsut we need to docuement it in the spec | 12:14 |
| sean-k-mooney | exciletn question i would say no | 12:14 |
| amoralej | uhh :) | 12:14 |
| sean-k-mooney | but the operaotr coudl pass that in vai the treshold | 12:14 |
| amoralej | i was thinking yes, tbh | 12:14 |
| amoralej | but right, its up to debate | 12:14 |
| sean-k-mooney | we dont want to premet if we are not out of capsity | 12:15 |
| winiciusallan[m] | amoralej: no, the strategy is based on the allocation | 12:15 |
| sean-k-mooney | but it depend on the input parmaters | 12:15 |
| winiciusallan[m] | because we would like guarantee free capacity | 12:15 |
| sean-k-mooney | if the treshold was 40% | 12:15 |
| sean-k-mooney | then yes it woudl peremet instance because the allcoation is over 50% | 12:15 |
| sean-k-mooney | *over 40% | 12:15 |
| winiciusallan[m] | yeah, thank you sean | 12:15 |
| amoralej | yes, i was thinking in threshold 75 i.e. | 12:15 |
| winiciusallan[m] | in this case, no instance will be preempted | 12:16 |
| dviroel | I see that allocation vs real usage are 2 different use cases | 12:16 |
| sean-k-mooney | yep | 12:16 |
| sean-k-mooney | the real susage is gettign clsoer to service assuarnce | 12:16 |
| dviroel | if the goal is to free allocation, shouldn't the strategy also check preemtible instances allocation only? | 12:16 |
| amoralej | i agree, but both may be treated in the same strategy | 12:16 |
| sean-k-mooney | i.e. nosiy neighbough | 12:16 |
| sean-k-mooney | they could or they coudl eb diffent | 12:17 |
| sean-k-mooney | but that is what we need to deciend in the spec | 12:17 |
| sean-k-mooney | and we can alwasy add new ones or extend them lather | 12:17 |
| amoralej | we may have two sets of threashold | 12:17 |
| amoralej | allocation_threshold and usage_threshold | 12:17 |
| sean-k-mooney | so i woudl focus on allcoation first but yes 2 threshodl for allcoation and usage coudl be ok | 12:17 |
| dviroel | + the resource to be checked right | 12:18 |
| dviroel | cpu, memory | 12:18 |
| amoralej | and disk ? | 12:18 |
| amoralej | i mean, local disk | 12:18 |
| dviroel | yep | 12:18 |
| jgilaber | if we do that, we'll need to pay attention to the UX | 12:18 |
| jgilaber | with that amount of parameters it could be confusing for users | 12:19 |
| winiciusallan[m] | just to ensure that I'm in the same page. in the case of utilization, are you guys talking about guarantee a % of utiliaztion instead of allocation? | 12:19 |
| jgilaber | we could end up like with zone migration | 12:19 |
| winiciusallan[m] | or when selecting candidate instances? | 12:19 |
| amoralej | another question, we'd account the resources globally (per-cluster or per-scope in the audit) or per-host?, i assume globally | 12:19 |
| winiciusallan[m] | good question amoralej. we can use audit scope for this, but I'm assuming for now cluster-wide resources | 12:20 |
| winiciusallan[m] | but would be a good addition (maybe in the future) to be able to scope to host or aggregate | 12:20 |
| dviroel | humm | 12:21 |
| amoralej | scope or cluster should be transparent for the audit, my question was more to ensure tha it's not per-host | 12:21 |
| dviroel | i think that it depends | 12:21 |
| sean-k-mooney | winiciusallan[m]: so utilisation need to be per host | 12:21 |
| sean-k-mooney | and vm on that host | 12:21 |
| sean-k-mooney | not lgoabl | 12:21 |
| sean-k-mooney | so if we had a usage treshold of 75% we woudl need to evulate the total workload utilissation on a host vs its capstiy | 12:21 |
| sean-k-mooney | and then if we exceed that for host with permtable isntance we woudl need to condier premeting them | 12:22 |
| dviroel | globally, we may end up freeing resources on different hosts, but still not have capacity for a new instance | 12:22 |
| winiciusallan[m] | yeah, it makes sense | 12:22 |
| sean-k-mooney | you could use your pipeline feature | 12:22 |
| winiciusallan[m] | so we would end up with fragmentation | 12:22 |
| sean-k-mooney | so you would do a premept pass folod by vm consolidation | 12:22 |
| sean-k-mooney | *followed | 12:23 |
| dviroel | right | 12:23 |
| dviroel | maybe allocation-based strategy could work globally | 12:23 |
| winiciusallan[m] | sean-k-mooney: this idea of usage threshold is more about in a noisy neighbour situation right? | 12:24 |
| dviroel | usage-based strategy I'm not sure. You may want a behavior like noisy neighbor for a usage-based strategy.. | 12:24 |
| winiciusallan[m] | what I'm indeed thinking is allocation to ensure that VMs can be created | 12:24 |
| dviroel | then it would be a per host analysis | 12:24 |
| amoralej | it's tricky | 12:25 |
| dviroel | so I think that allocation vs usage could even be 2 different strategies in the end? | 12:25 |
| jgilaber | I was thinking that same thing dviroel | 12:25 |
| amoralej | but they may interact poorly | 12:25 |
| amoralej | i.e. if a spot instance is going to be removed because of allocation limit, it's usage should take into account when calculating usage | 12:26 |
| amoralej | or the other way around | 12:26 |
| sean-k-mooney | dviroel: i was expecitng them to be seprate stragies as well yes | 12:27 |
| amoralej | i think spot instances should be treated in the same | 12:27 |
| amoralej | i mean, both use cases in the same | 12:27 |
| dviroel | but the use case that winiciusallan[m] wants to cover is more related to allocation. A No valid Host error could be a trigger for this Audit. Is that it winiciusallan[m] ? | 12:27 |
| sean-k-mooney | i think those are two diffent optimsation approch so combining them seam more complicte to start with | 12:28 |
| sean-k-mooney | for what it worht i woudl be fien if thies state out only based on allcaotion | 12:28 |
| amoralej | ok, we can start with allocations only, but let's clearly explain it | 12:28 |
| winiciusallan[m] | dviroel: a NoValidHost should not be trigger i would say | 12:28 |
| sean-k-mooney | and we defered usage based premetion till later unless winiciusallan[m] wants to do that now | 12:28 |
| winiciusallan[m] | but it can happens | 12:28 |
| amoralej | given that spot instances may affect performance on non-spot | 12:29 |
| sean-k-mooney | amoralej: i woudl really not like to bring that into the scope fo this | 12:29 |
| sean-k-mooney | not until we have the allcoation based premation doen first | 12:29 |
| sean-k-mooney | the oginaly converation about usage | 12:29 |
| sean-k-mooney | was if i have 2 vms that can be premetned | 12:29 |
| sean-k-mooney | on a given host | 12:29 |
| winiciusallan[m] | amoralej: that is what was confusing me because you can follow a lot of heuristics to decide when preempt instances | 12:29 |
| sean-k-mooney | which one do i choose | 12:29 |
| sean-k-mooney | the oldes or the least used | 12:30 |
| winiciusallan[m] | but I think it will be simpler go for the allocation case | 12:30 |
| sean-k-mooney | so there are 2 seperat thigns shoudl we prement and if so what do we prement | 12:30 |
| amoralej | ok, i'm fine with going only with the allocation case, just let's clearly document | 12:30 |
| sean-k-mooney | usage and allcaotion are interesting for both | 12:30 |
| winiciusallan[m] | ack amoralej | 12:31 |
| sean-k-mooney | winiciusallan[m]: what i woudl preopsoe for v1 (we can go into more detail in the spec) is this | 12:31 |
| sean-k-mooney | use allcation as teh treshsold for shoudl we prement | 12:32 |
| sean-k-mooney | and supprto 2-3 poslics for which premetabel isnts to prement | 12:32 |
| sean-k-mooney | age size adn usage are the 3 for which to prement that i think make sense | 12:32 |
| sean-k-mooney | after we have decied based ont the threshold tha twe should preempt | 12:32 |
| winiciusallan[m] | ack | 12:33 |
| sean-k-mooney | winiciusallan[m]: if you have other ideas of course feel free to propsoe those | 12:33 |
| winiciusallan[m] | i've already put two of these | 12:33 |
| winiciusallan[m] | will work on adding one more | 12:33 |
| sean-k-mooney | ill try and make tiem for this spec before the next meeting | 12:33 |
| winiciusallan[m] | ack | 12:34 |
| winiciusallan[m] | thank you all for the feedback :) | 12:34 |
| dviroel | ok, it seems that we are aligned with this | 12:35 |
| dviroel | we then can focus on reviewing the spec in the following week | 12:35 |
| dviroel | and discuss more in gerrit or in next meetings | 12:35 |
| dviroel | any other question or concern about that? | 12:36 |
| winiciusallan[m] | nothing from my side | 12:36 |
| winiciusallan[m] | thanks for raising my topic | 12:36 |
| dviroel | as for the next topic that I added, we have a release schedule to follow | 12:36 |
| dviroel | thanks winiciusallan[m] for bringing the discussion here | 12:36 |
| dviroel | #topic Hibuscus Schedule | 12:37 |
| dviroel | #link https://static.openstack.org/project/releases.openstack.org/hibiscus/schedule.html | 12:37 |
| dviroel | we are 3 weeks aways from milestone 2 | 12:37 |
| dviroel | which is our spec freeze deadline too | 12:37 |
| sean-k-mooney | we are also jsut past the mid poing fo the cyle i belive | 12:38 |
| dviroel | some teams have different deadlines, and have their spec freeze this week for instance | 12:38 |
| sean-k-mooney | ya nova is very very early this release | 12:38 |
| dviroel | yeah, nova and manila (R-16) | 12:39 |
| dviroel | we are in the schedule with the specs open/merged | 12:39 |
| dviroel | jgilaber also added a reminder about release tasks, thanks for following up | 12:39 |
| dviroel | anything else related to the schedule? | 12:40 |
| dviroel | otehrwise we can move to Reviews | 12:40 |
| jgilaber | when the time comes we can think if we want to make a stable release | 12:40 |
| jgilaber | we don't have a lot of changes right now | 12:40 |
| dviroel | ack, we need to focus on merging some backports too | 12:41 |
| jgilaber | we have a few for the 2025 branches and just one for 2026.1 | 12:41 |
| sean-k-mooney | maybe do a stabel review day in the next week or two | 12:41 |
| dviroel | yeah, as we discussed at the ptg, that would help | 12:41 |
| sean-k-mooney | why not next thrsday | 12:42 |
| sean-k-mooney | we can do soem revdiew and check in on the progress in the meeting | 12:42 |
| dviroel | it works for me | 12:42 |
| jgilaber | +1 | 12:43 |
| amoralej | +1 | 12:43 |
| dviroel | #action stable review day next thurday Jun 18th | 12:43 |
| dviroel | I may start on 17th :) | 12:44 |
| dviroel | ok, lets move to next topic | 12:44 |
| dviroel | running out of time | 12:44 |
| dviroel | #topic Reviews | 12:44 |
| dviroel | #link https://review.opendev.org/q/topic:%22use-openstacksdk%22+project:openstack/watcher+status:open | 12:44 |
| dviroel | jgilaber: o/ | 12:44 |
| jgilaber | I've pushed a few more patches to migrate the placement helper to use the sdk | 12:44 |
| dviroel | ++ | 12:44 |
| jgilaber | I remove some unused methods in the very first patch | 12:45 |
| dviroel | i love to delete unused code | 12:45 |
| jgilaber | and then I do the usual creating classes, swithcing + cleanup at the end | 12:45 |
| jgilaber | like keystone, the placement helper has little functionality, so the patches are not too big | 12:45 |
| dviroel | ack, the L patches seems to be more delete than add | 12:46 |
| jgilaber | the second link is for an old patch to remove the retry logic we had in the NovaHelper | 12:46 |
| jgilaber | #link https://review.opendev.org/c/openstack/watcher/+/975498 | 12:46 |
| * dviroel not this one :P | 12:47 | |
| jgilaber | I found another bug in the sdk regarding the retries code so I had to wait for another release | 12:47 |
| jgilaber | but this week it came out and I could test everything and it seems to work | 12:47 |
| jgilaber | I've kept the old defaults with the new parameters | 12:47 |
| jgilaber | 3 retries, 2 seconds delay | 12:47 |
| jgilaber | the patch will fail in CI until the uppers-constraints in the requirement repo is updated for the sdk | 12:48 |
| dviroel | ok so the latest fix is in openstacksdk 4.15 | 12:48 |
| jgilaber | that's right | 12:48 |
| jgilaber | that's all I wanted to say, we can address any feedback in gerrit | 12:49 |
| dviroel | ack for the upper constraints, thanks for persuing and fixing this | 12:49 |
| dviroel | jgilaber++ | 12:49 |
| amoralej | yep, thanks jgilaber, i'll try to review part of that at least in the incoming days | 12:49 |
| dviroel | any other questions folks? | 12:49 |
| dviroel | next is | 12:49 |
| dviroel | "Replace the process-wide global lock @lockutils.synchronized("model_root") with an per instance RLock" | 12:50 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher/+/987540 | 12:50 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher/+/988297 | 12:50 |
| dviroel | the second link is the regression test | 12:50 |
| dviroel | jgilaber: sean-k-mooney chandankumar morenod ^ please review when you have some time | 12:50 |
| dviroel | this fix should improve our strategies by replacing the current locking system | 12:51 |
| amoralej | it does, actually :) | 12:51 |
| dviroel | since strategies do a copy of the model, per-instance lock makes more sense here | 12:52 |
| dviroel | amoralej: TY for testing the changes++ | 12:52 |
| amoralej | in my tests with workload_stabilization, i.e. it reduces execution time to almost half | 12:52 |
| dviroel | these ones fixes the locking model | 12:53 |
| dviroel | there are 2other ones that improves workload_stabilization algorithym | 12:53 |
| dviroel | which we may discuss in gerrit on in another meeting | 12:53 |
| amoralej | yep, that can be a long discussion :) | 12:54 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher/+/988297 | 12:54 |
| dviroel | and | 12:54 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher/+/988533 | 12:54 |
| dviroel | thanks amoralej and winiciusallan[m] for reviewing them :) | 12:55 |
| dviroel | ack, the next one is | 12:55 |
| dviroel | "Fix scalability for vm_workload_consolidation" | 12:55 |
| dviroel | #link https://review.opendev.org/c/openstack/watcher/+/992676 | 12:55 |
| dviroel | this is new right | 12:55 |
| dviroel | amoralej: | 12:55 |
| amoralej | i just sent that today | 12:55 |
| amoralej | in my scale tests with simulator, that fixes the main scalability issues | 12:56 |
| amoralej | in the real scalability tests we did some months ago, we didn't get the strategy finishing after waiting more than one hour | 12:56 |
| amoralej | we got the same result with the simulator | 12:56 |
| amoralej | and with the patch, it takes ~ 14 minutes in my environment | 12:57 |
| amoralej | actually, i'd expect to take less time in a real environment, but i think it's a good test | 12:57 |
| amoralej | so only that, keep that one in mind when you get some review time :) | 12:58 |
| * dviroel my chrome is freezing with some gerrit changes... | 12:58 | |
| dviroel | ack, thanks amoralej | 12:58 |
| dviroel | i will take a look, I already have a question in mind, but I need to look your patch with details. | 12:59 |
| dviroel | #topic Bugs | 12:59 |
| dviroel | we are out of time,but morenod bugs are there for a while | 12:59 |
| dviroel | morenod: do you want to highlight one of them? | 12:59 |
| morenod | I updated this morning the descriptions, with more context and reproducing steps | 13:00 |
| dviroel | thanks for that | 13:00 |
| amoralej | yeah, much more clear now :) | 13:00 |
| dviroel | it may help some ai agents reproducers :) | 13:00 |
| sean-k-mooney | so | 13:01 |
| sean-k-mooney | #link https://bugs.launchpad.net/watcher/+bug/2154805 | 13:01 |
| dviroel | they seems to have the same importance | 13:01 |
| sean-k-mooney | #link https://bugs.launchpad.net/watcher/+bug/2154806 | 13:01 |
| sean-k-mooney | #link https://bugs.launchpad.net/watcher/+bug/2154807 | 13:01 |
| sean-k-mooney | correct | 13:01 |
| dviroel | yes | 13:02 |
| sean-k-mooney | ya so the dectipion look reasonable to me | 13:02 |
| amoralej | i think we discussed them to be medium ? | 13:02 |
| sean-k-mooney | ya i think medium is correct here | 13:02 |
| jgilaber | +1 medium seems reasonable | 13:03 |
| sean-k-mooney | i guess the decision-engine tag | 13:03 |
| sean-k-mooney | we dotn ahve scope so i think decision-engine is the most fitting | 13:03 |
| dviroel | yeah | 13:03 |
| jgilaber | +1 | 13:04 |
| dviroel | i made the changes | 13:04 |
| dviroel | someone is planning to work on these? | 13:04 |
| dviroel | if yes, please assign it to you | 13:05 |
| amoralej | not in next days at least | 13:05 |
| dviroel | so people know that someone is already working on it | 13:05 |
| dviroel | ack | 13:05 |
| sean-k-mooney | ya probaly not in the next week or so | 13:05 |
| sean-k-mooney | but if i do ill asgin it or check with folks first | 13:05 |
| dviroel | thanks folks | 13:06 |
| dviroel | #topic Volunteers to chair next meeting | 13:06 |
| dviroel | next week we will circle back the stable branches reviews | 13:06 |
| dviroel | i can take the meeting again, unless someone wants to chair | 13:06 |
| dviroel | ok, so we meet again next week | 13:07 |
| dviroel | let's wrap up for today | 13:07 |
| dviroel | sorry for extending the meeting | 13:07 |
| dviroel | thank you all for participating | 13:07 |
| dviroel | #endmeeting | 13:07 |
| opendevmeet | Meeting ended Thu Jun 11 13:07:46 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-06-11-12.01.html | 13:07 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-06-11-12.01.txt | 13:07 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-06-11-12.01.log.html | 13:07 |
| amoralej | thanks dviroel for chairing! | 13:08 |
| sean-k-mooney | by the way there si sort of 2 bugs in those bugs | 13:08 |
| sean-k-mooney | openstack server create --flavor m1.tiny --image cirros \ | 13:08 |
| sean-k-mooney | --availability-zone nova:compute-1 instance-1 | 13:08 |
| sean-k-mooney | when you adminsitvialy boot a hsot and force a host like that | 13:09 |
| sean-k-mooney | you are kind of pinning the vm to hte host | 13:09 |
| sean-k-mooney | fi yo shelve and unshelve it for exampel we will try and put it back on the same host | 13:10 |
| sean-k-mooney | so the sort of bug is watche has no awarness fo that in general | 13:10 |
| sean-k-mooney | and that it shodl not try to mvoe vms that were forced to a specifc host in the first place | 13:11 |
| dviroel | ack, to "force" a host during the test, it is easier to disable the other compute services, create the servers, and then enable the compute services again | 13:11 |
| sean-k-mooney | the worklaod consodliation/blance strageis for example shoudl avoid movign them | 13:11 |
| sean-k-mooney | dviroel: this is also fine it does not realy invalidat ehte test in this specifc case | 13:12 |
| sean-k-mooney | but just an aside that force host ectra is not somethign watcher really knows about | 13:12 |
| sean-k-mooney | we will need to eventualy adress that | 13:12 |
| dviroel | yes | 13:12 |
| sean-k-mooney | for telcos this is genreally pretty imporant for normla clouds this is rarely used and kind of an anti pattern | 13:14 |
| sean-k-mooney | which is partly why we restict forcign a host to admin only in defautl policy | 13:14 |
| opendevreview | Merged openstack/watcher master: Add regression test for map_instance reentrant deadlock https://review.opendev.org/c/openstack/watcher/+/988297 | 16:02 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!