| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove unused CinderHelper methods https://review.opendev.org/c/openstack/watcher/+/994841 | 06:15 |
|---|---|---|
| opendevreview | Joan Gilabert proposed openstack/watcher master: Add dataclass wrappers for CinderHelper API objects https://review.opendev.org/c/openstack/watcher/+/994842 | 06:15 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Replace python-cinderclient with openstacksdk https://review.opendev.org/c/openstack/watcher/+/994843 | 06:15 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove python-cinderclient dependency https://review.opendev.org/c/openstack/watcher/+/994844 | 06:15 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Move db fixtures to the common fixtures directory https://review.opendev.org/c/openstack/watcher/+/988388 | 06:17 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Add functional test framework for Watcher https://review.opendev.org/c/openstack/watcher/+/988389 | 06:17 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Add Nova/Placement emulators and host_maintenance functional tests https://review.opendev.org/c/openstack/watcher/+/993352 | 06:17 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Add Prometheus emulator and workload_stabilization functional tests https://review.opendev.org/c/openstack/watcher/+/993543 | 06:17 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Add Cinder emulator and zone_migration functional tests https://review.opendev.org/c/openstack/watcher/+/993634 | 06:17 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Fix race condition in DefaultLoader._reload_config() https://review.opendev.org/c/openstack/watcher/+/994845 | 06:17 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: [ci] Increase CI jobs timeouts https://review.opendev.org/c/openstack/watcher/+/994847 | 06:29 |
| amoralej | sean-k-mooney, dviroel ^ I'm proposing to increase jobs timeouts until we can land the optimizations, jobs are failing often and we are wasting a lot of resources in rechecks | 06:30 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Add volume_type, created_at and host fields to volumes in model https://review.opendev.org/c/openstack/watcher/+/994777 | 07:32 |
| opendevreview | Alfredo Moralejo proposed openstack/watcher master: Remove Cinder API calls from zone_migration strategy https://review.opendev.org/c/openstack/watcher/+/994778 | 07:32 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Add dataclass wrappers for CinderHelper API objects https://review.opendev.org/c/openstack/watcher/+/994842 | 08:42 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Replace python-cinderclient with openstacksdk https://review.opendev.org/c/openstack/watcher/+/994843 | 08:42 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove python-cinderclient dependency https://review.opendev.org/c/openstack/watcher/+/994844 | 08:42 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Use real objects in volume migration tests https://review.opendev.org/c/openstack/watcher/+/994862 | 08:42 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Replace python-cinderclient with openstacksdk https://review.opendev.org/c/openstack/watcher/+/994843 | 08:49 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove python-cinderclient dependency https://review.opendev.org/c/openstack/watcher/+/994844 | 08:49 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Use real objects in volume migration tests https://review.opendev.org/c/openstack/watcher/+/994862 | 08:49 |
| sean-k-mooney | amoralej: ok i fast approved that for now | 11:09 |
| sean-k-mooney | letss see if we can revert it in the next week or two | 11:09 |
| sean-k-mooney | ill look at reworking https://review.opendev.org/c/openstack/watcher/+/994327 later today | 11:10 |
| sean-k-mooney | i think dviroel change for tempest is approved? | 11:10 |
| amoralej | it was failing to merge because of timeouts :) that's wat lead me to send the timeout increase | 11:35 |
| jgilaber | Hi all, IRC meeting starting in 5 minutes, add your topics to the agenda https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L31 | 11:55 |
| dviroel | yeah, it seems that we still have some timeouts hapenning even after changing intervals to 1s | 11:57 |
| jgilaber | #startmeeting watcher | 12:01 |
| opendevmeet | Meeting started Thu Jun 25 12:01:07 2026 UTC and is due to finish in 60 minutes. The chair is jgilaber. 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 |
| jgilaber | Hi all! Who is around today? | 12:01 |
| dviroel | o/ | 12:01 |
| jgilaber | While we gather, feel free to add topics to the agenda https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L31 | 12:01 |
| jgilaber | courtesy ping: amoralej sean-k-mooney chandankumar morenod rlandy | 12:01 |
| rlandy | o/ | 12:02 |
| amoralej | o/ | 12:02 |
| chandankumar | o/ | 12:02 |
| sean-k-mooney | o/ | 12:02 |
| jgilaber | let's start with the first topic for today | 12:03 |
| jgilaber | #topic Change irc meeting to one hour later | 12:03 |
| jgilaber | last week it was proposed to change the time of the irc meeting | 12:04 |
| jgilaber | to one hour later (13:00 UTC) - continue to be weekly on Thursday | 12:04 |
| jgilaber | any objections to that? if not we could start with the new time next week | 12:04 |
| dviroel | works for me +1 | 12:05 |
| rlandy | +1 | 12:05 |
| chandankumar | +1 | 12:05 |
| jgilaber | no objections from me either | 12:05 |
| sean-k-mooney | yep im fine with that | 12:05 |
| sean-k-mooney | jgilaber: are you goign to update the oficall meetins repo? | 12:05 |
| jgilaber | #agreed new time for Watcher IRC meeting 13:00 UTC | 12:06 |
| sean-k-mooney | we should send a mail to the list after that is done | 12:06 |
| sean-k-mooney | just as an fyi | 12:06 |
| dviroel | we meed to update the repo and it is good to send a email to ML | 12:06 |
| sean-k-mooney | yep ^ | 12:06 |
| jgilaber | I can do it sure, does anyone have a link to the repo handy? | 12:06 |
| sean-k-mooney | no | 12:07 |
| sean-k-mooney | i actyully dont rememeber where that goes | 12:07 |
| dviroel | hum | 12:07 |
| jgilaber | ack, I'll look around after the meeting and we can move to the next topic | 12:07 |
| winiciusallan[m] | o/ | 12:08 |
| rlandy | well https://wiki.openstack.org/wiki/Watcher#Meetings still has the older time | 12:08 |
| sean-k-mooney | i know we did it a while back let me check my review history | 12:08 |
| rlandy | so we might want to update that | 12:08 |
| sean-k-mooney | rlandy: right we don tuse that page anyjmore | 12:08 |
| sean-k-mooney | ya that or delete it | 12:08 |
| rlandy | +1 | 12:08 |
| dviroel | https://opendev.org/opendev/irc-meetings | 12:08 |
| rlandy | because it's on our channel heading | 12:08 |
| jgilaber | thanks dviroel ++ | 12:08 |
| sean-k-mooney | opendev/irc-meetings | 12:09 |
| sean-k-mooney | ah you also just found it | 12:09 |
| jgilaber | I think that is all I needed, we can proceed with the next topic unless there is anything else | 12:09 |
| dviroel | ++ | 12:10 |
| jgilaber | #topic specs open | 12:10 |
| jgilaber | #link https://review.opendev.org/q/project:openstack/watcher-specs+is:open | 12:10 |
| jgilaber | we have three specs open for review | 12:10 |
| dviroel | there was 1 open until yesterday :) | 12:10 |
| dviroel | jgilaber: lets quikly go over them | 12:11 |
| jgilaber | #link https://review.opendev.org/c/openstack/watcher-specs/+/994807 | 12:11 |
| jgilaber | this one is new from dviroel | 12:11 |
| dviroel | ack, i just sent this one yesterday | 12:11 |
| dviroel | it is very close to the deadline | 12:11 |
| dviroel | so we may not get it merged/ready for this cycle | 12:11 |
| dviroel | but still something that we started discussing in the ptg | 12:12 |
| dviroel | amoralej: already added some comments, thanks! | 12:12 |
| dviroel | the tl;dr; | 12:12 |
| dviroel | it is about filtering instances/destination hosts that we know that would fail in nova migrate, but watcher doesn't account that | 12:12 |
| dviroel | most simple cases: | 12:12 |
| dviroel | affinity and anti-affinity hosts, pinned azs | 12:13 |
| dviroel | or any other constraints that we know that are not supported for live-migration for instance | 12:13 |
| dviroel | as Alfredo already commented in the spec | 12:14 |
| dviroel | this can grow and do more things for strategies | 12:14 |
| sean-k-mooney | so i have not had time to look at it | 12:14 |
| dviroel | but the proposal for now, is to simplify and remove invalid hosts/instances from the entire list | 12:14 |
| sean-k-mooney | but being realistic do you really think you would be able to do that in addtion to the pipeline work this cycle | 12:14 |
| sean-k-mooney | my incliaiton is to say given we are a week for spec freeze we shoudl likely create the 2027.1 folder next week and move this to that | 12:15 |
| dviroel | sean-k-mooney: i would like, but I don't think that is feasible since I really think that pipeline will still have lots of issues to handle | 12:15 |
| jgilaber | I think moving some of the open ones to 2027.1 sounds reasonable also from the review side | 12:16 |
| dviroel | also, that spec expects that scheduler_hints would be available too | 12:16 |
| jgilaber | we're quite close to spec freeze | 12:16 |
| sean-k-mooney | ya so my suggestion woudl be to propose this for next cycel, we can continue reviewing it and even merge it if its reay over the next month or two | 12:16 |
| dviroel | which is not yet truth | 12:16 |
| sean-k-mooney | but not aim to have it merged in the next week :) | 12:16 |
| dviroel | yeah, I would like to work on that once audit pipeline is ready | 12:16 |
| dviroel | i was not expecting to merge it too | 12:17 |
| sean-k-mooney | dviroel: right is we coudl do the nova prequistit this cyles that would be good | 12:17 |
| dviroel | since we already mention that | 12:17 |
| sean-k-mooney | that the addtion of the field to the notificion obejct yes? | 12:17 |
| dviroel | sean-k-mooney: it is another | 12:17 |
| dviroel | but we need both in the end | 12:17 |
| sean-k-mooney | ack | 12:17 |
| dviroel | but this specs would require sched_hints in the CDM | 12:17 |
| dviroel | and for that, i would just create a blueprint now | 12:18 |
| sean-k-mooney | so i think we will be in a similar state for https://review.opendev.org/c/openstack/watcher-specs/+/994607 | 12:18 |
| amoralej | I'd like to give that a try in this cycle | 12:18 |
| dviroel | so for filters, we may have a poc during this cycle | 12:18 |
| sean-k-mooney | i think we coudl poc both this cyle | 12:19 |
| sean-k-mooney | but i dont think we will have the design review completed by july 2nd | 12:19 |
| dviroel | so yeah, I can update the spec to 2027.1 and create a poc | 12:19 |
| amoralej | we can poc before merging the spec? | 12:19 |
| dviroel | we should | 12:19 |
| sean-k-mooney | well july 4th technialy | 12:19 |
| dviroel | the idea of the poc is to validate the proposal, which gives more insights to the spec in the end | 12:20 |
| sean-k-mooney | if we can do pocs of both i thinik we coudl trage to merge them before the end of year all goign well even in q3 potically | 12:20 |
| sean-k-mooney | i just think august would be agressive | 12:20 |
| dviroel | yeah, in addition to that, we would require more time from reviewers too | 12:21 |
| amoralej | but i'd appreciate if you can leave any feedback without waiting for the poc | 12:21 |
| dviroel | this ^ needs to be considered | 12:21 |
| sean-k-mooney | amoralej: im happy to review it | 12:21 |
| sean-k-mooney | just not going to commit to doign it in the nextg week | 12:21 |
| dviroel | amoralej: sure, we can discuss the proposal without the poc | 12:21 |
| amoralej | yep, I guess reviewing is going to be the bottleneck | 12:21 |
| sean-k-mooney | ill take a look but it may take me a day or so | 12:22 |
| amoralej | sure | 12:22 |
| dviroel | ok | 12:22 |
| dviroel | next spec then jgilaber | 12:22 |
| sean-k-mooney | im currently reviewing the premetiabel instance spec | 12:22 |
| sean-k-mooney | which is | 12:22 |
| sean-k-mooney | #link https://review.opendev.org/c/openstack/watcher-specs/+/987171/7/specs/2026.2/approved/preemptible-instances.rst | 12:22 |
| dviroel | +1 | 12:22 |
| dviroel | winiciusallan[m]: o/ | 12:22 |
| winiciusallan[m] | o/ | 12:22 |
| dviroel | we need to focus in your spec this week | 12:23 |
| dviroel | I need to review your last updates | 12:23 |
| amoralej | my only doubt about that is about the order criteria as commented | 12:23 |
| winiciusallan[m] | i'm addressing comments that you guys are leaving there | 12:23 |
| winiciusallan[m] | amoralej: left a good comment regarding the utilization policy | 12:23 |
| dviroel | but this week we need to address all the missing details | 12:23 |
| dviroel | and close any open gap | 12:23 |
| dviroel | but in general seems to be in a good direction | 12:24 |
| dviroel | lets see what other reviewers will say about that | 12:24 |
| sean-k-mooney | so im only as fart as the `Optimization Target` in my review today, i have skimmed other parts but not of the latest verion | 12:24 |
| winiciusallan[m] | amoralej: regarding your comment about preempting more instances than the necessary, I think this is a consequence of having utilization as criteria | 12:24 |
| winiciusallan[m] | but we could add one more which would be "best_fit" or something like that | 12:25 |
| winiciusallan[m] | wdyt? | 12:25 |
| sean-k-mooney | it depend on how you do it | 12:25 |
| dviroel | we just need to be caution on adding to many requirements to the first version of it | 12:26 |
| sean-k-mooney | there are kind of 2 seperate thing first determin if we need to do peremtion at all | 12:26 |
| sean-k-mooney | adn then if we do what instnace to prempt to achive the goal | 12:26 |
| sean-k-mooney | for the utilsiation based selction critia | 12:27 |
| sean-k-mooney | we would need to only selcect instnace who's capsicty is less then the remainign gap to the treshold | 12:27 |
| sean-k-mooney | and choose the least utilized vm in each pass until we reach it | 12:28 |
| sean-k-mooney | somethign liek that if we dont want to over prement | 12:28 |
| sean-k-mooney | i.e. we likely want a target and a margin of error and stop when we run out of instance that meet the critiria | 12:28 |
| amoralej | so, we need to define the criteria. Making it only depend on utilization (lower utilization is terminated first) may lead to more terminated instances. I'm not saying that's bad, but needs to be defined | 12:29 |
| dviroel | based on the use case define in the spec yeah | 12:30 |
| amoralej | and then we should avoid mention "minimizing the number of terminated instances" as main goal | 12:30 |
| sean-k-mooney | right utilsiation is a sorting function but capsity iss the treshold we use for proceeding to the next instnace | 12:30 |
| amoralej | yep | 12:30 |
| sean-k-mooney | for what its worth i think you may want to apply both age and another metirc | 12:31 |
| amoralej | an interesting one is about age of the vm mentioned in the spec, would it make sense to avoid terminating vms created less that a certain time ago? | 12:31 |
| amoralej | dunno how cloud providers manage it, tbh | 12:31 |
| sean-k-mooney | for example gcp and aws have a minium age before they will prement a spot instnace | 12:31 |
| sean-k-mooney | of 1 hour | 12:31 |
| amoralej | ^ yeap, that's what i mean | 12:31 |
| winiciusallan[m] | hm that's interesting | 12:31 |
| sean-k-mooney | i.e. we shoudl be able to express that | 12:31 |
| dviroel | makes sense | 12:32 |
| sean-k-mooney | but again that part of the filtering critira rather then the selection critira | 12:32 |
| winiciusallan[m] | right, i will add a new input_parameter for this and will remove mentions about the number of preempted instances | 12:32 |
| amoralej | that may be not an ordering by date, but a true|false, if instances are less than 1hr old, move at the end of the list | 12:32 |
| sean-k-mooney | so i would do this by first filtering the candiate isntace to remove all instnce that were created less then the min_age | 12:32 |
| amoralej | we may preempt them in case it's the only option to achieve the goal | 12:33 |
| sean-k-mooney | and hten sort that list by utilistation | 12:33 |
| sean-k-mooney | and filter out instance that are larger then the remaining treaholdd gap on each iteration | 12:33 |
| sean-k-mooney | amoralej: well or not | 12:33 |
| sean-k-mooney | i would prefer to not prement them and not fully achvie teh goal | 12:33 |
| sean-k-mooney | so that operatrs can provide the public contract | 12:33 |
| sean-k-mooney | but that is somethign that could be express in the parmater to the audit | 12:34 |
| winiciusallan[m] | sean-k-mooney: if we will sort by utilization is configurable. the user can choose for another policy e.g. oldest | 12:34 |
| sean-k-mooney | winiciusallan[m]: exactly | 12:34 |
| amoralej | maybe an unrealistic corner case but, what if all spot instances are big, bigger that what we need to achieve the goal? in that case i would preempt the smallest | 12:34 |
| sean-k-mooney | that why i think we need to have filtering + priotisation/sorting and revalauation to the target in a loop | 12:35 |
| sean-k-mooney | amoralej: taht could be an option yes | 12:35 |
| winiciusallan[m] | amoralej: i think would still be good to order by oldest. this avoids instances running for too long as spot | 12:35 |
| sean-k-mooney | so we dont need to cather for all these option in v1 | 12:35 |
| sean-k-mooney | amoralej: that backfil mecanic could be added on once the basic case is fucntional | 12:36 |
| sean-k-mooney | that basiclly a tweak to the filtering/are we done yet critia | 12:36 |
| dviroel | yeah, i would like to see the minimal working first, have it properly tested before the release deadlines | 12:37 |
| winiciusallan[m] | +1 | 12:37 |
| amoralej | last question, so we prefer to preemt more small unused instances than a bigger one ? | 12:37 |
| dviroel | and maybe tackle corner cases afterwards | 12:37 |
| sean-k-mooney | in that specific case the first iteration of the loop would be empty, we would have not achive the goal and then we have a final premation of 1 instnace optional to tray and achive the goal | 12:37 |
| sean-k-mooney | amoralej: form talign to operators | 12:37 |
| sean-k-mooney | ovh prefe to premet medium sized vms | 12:38 |
| winiciusallan[m] | amoralej: i would say that following the utilization policy, yes, that will be behavior | 12:38 |
| sean-k-mooney | but i think that a policy chocie that we likely dont want to hard code in the long term | 12:38 |
| amoralej | that'd may also lead to fragmentation, so that globally we achieve the goal but not in a single compute node so can't hold bigger flavors | 12:39 |
| amoralej | anyway, i think we'll learn and improve over time, as soon as the implementation leaves the places to implement selection mechanim in future | 12:39 |
| sean-k-mooney | amoralej: we likly will want to have a prefence filed for larget,oldest,smaleset ectra, low unitistation, high... | 12:39 |
| amoralej | ack | 12:40 |
| sean-k-mooney | ill try an dcoment on the spec but one thing | 12:40 |
| sean-k-mooney | preempted_instances_count | 12:40 |
| sean-k-mooney | as an efficacy indicator | 12:40 |
| winiciusallan[m] | I can add to the spec a note about fragmentation. I thought I have added. | 12:40 |
| sean-k-mooney | we want to minimise the number of premented instance in most case | 12:41 |
| sean-k-mooney | but that will depedn on the policy chosen | 12:41 |
| sean-k-mooney | every instance we premept is a workload impact for the custoemr | 12:41 |
| sean-k-mooney | at least by default | 12:42 |
| sean-k-mooney | btu if the operator want to prefer smaller vms and sets an agress target then preempted_instances_count will be high | 12:42 |
| sean-k-mooney | vs prefering the bigest instnace | 12:42 |
| winiciusallan[m] | this can be empiric evaluated about works better for a specific environment. there are a lot of ways of choosing which instance to premept | 12:42 |
| sean-k-mooney | so to me i dont think preempted_instances_count is a good efficacy Indicator | 12:42 |
| sean-k-mooney | in general | 12:42 |
| winiciusallan[m] | ack | 12:43 |
| sean-k-mooney | winiciusallan[m]: that does nto mean we cant report that value | 12:43 |
| sean-k-mooney | im just noting that the resouce change is likely more directly useful | 12:43 |
| amoralej | i think it's valuable information for the operator even if not the goal itself | 12:43 |
| dviroel | it is a good indicator, but maybe is not really related to efficacy? | 12:44 |
| dviroel | yeah, is more a interesting info | 12:45 |
| amoralej | actually, i'd also add some indication on how many preemtible indicatores are non-preemted | 12:45 |
| winiciusallan[m] | as a report value for the operator, would this be as an efficacy indicator or somewhere else? | 12:45 |
| jgilaber | I don't want to discourage the discussion, but we've got only 15 minutes left and a few more topics, ok to move the discussion to the review? | 12:45 |
| amoralej | right, but there is no other way to give information of audit results in watcher api | 12:45 |
| dviroel | jgilaber: +1 | 12:45 |
| amoralej | +1 | 12:45 |
| winiciusallan[m] | ack jgilaber_ | 12:45 |
| dviroel | we can continue in the spec or here in the channel later | 12:46 |
| dviroel | and during the week | 12:46 |
| jgilaber | thanks for the input folks, that was the last spec to flag | 12:46 |
| dviroel | winiciusallan[m]: if you need answers faster, we can just chat in the channel | 12:46 |
| jgilaber | let's try to review them and see which ones we can fit in this cycle | 12:46 |
| dviroel | and not just wait for a feedback in gerrit | 12:46 |
| dviroel | ++ | 12:46 |
| jgilaber | next topic | 12:46 |
| jgilaber | #topic Blueprint updates: | 12:47 |
| jgilaber | #link https://etherpad.opendev.org/p/watcher-blueprints-2026.2 | 12:47 |
| jgilaber | from dviroel | 12:47 |
| dviroel | jgilaber: in the end we skipped amoralej spec? | 12:47 |
| jgilaber | oh sorry I thought we discussed it already | 12:47 |
| dviroel | not sure | 12:47 |
| jgilaber | #link https://review.opendev.org/c/openstack/watcher-specs/+/994607 | 12:47 |
| jgilaber | sorry amoralej | 12:47 |
| dviroel | amoralej: want to highlight something about this spec ^ | 12:48 |
| amoralej | i think the most effective is to read when you have a chance, no problem | 12:48 |
| amoralej | what i'm proposing is to create new planners following a composable architecture | 12:48 |
| dviroel | it is a good proposal but I didn't have enough time to read | 12:48 |
| amoralej | keep the existing ones as they are | 12:49 |
| dviroel | ack | 12:49 |
| amoralej | and provide a mechanism to override the planner to be used on each strategy in config | 12:49 |
| amoralej | not worthy to go into details now, i think, we can discuss in future meetings | 12:49 |
| dviroel | ok | 12:49 |
| dviroel | so we can move on | 12:49 |
| dviroel | not going to spend to much time in the blueprint topic | 12:50 |
| dviroel | just want to highlight that we have a bunch of approved blueprint | 12:50 |
| dviroel | but without tracking of patches or implementation | 12:51 |
| amoralej | https://blueprints.launchpad.net/watcher/+spec/skip-actions-in-pre-condition is finished | 12:51 |
| dviroel | thanks amoralej, i was expecting that yeah | 12:51 |
| amoralej | dunno how to change Status or who can do it | 12:52 |
| dviroel | i will still search the code for any merged patch around the old approved blueprint | 12:52 |
| dviroel | is that ok to update them to obselete in this case? wdyt? | 12:53 |
| dviroel | the most recent one, like the one that Alfredo mentioned is easier to update since we know if we still have some pending work or not | 12:53 |
| dviroel | amoralej: it may require permission to to that | 12:53 |
| dviroel | sean and I can update it | 12:53 |
| jgilaber | I'd say so unless it implemented a significant fraction of the work proposed | 12:54 |
| dviroel | yep | 12:54 |
| jgilaber | which might be hard if they don't have enough context | 12:54 |
| dviroel | so the TL;DR; is that I am planning to do some cleanup and update, as also guarantee that new feature will also have their own blueptints | 12:54 |
| amoralej | +1 | 12:55 |
| jgilaber | +1 thanks dviroel | 12:55 |
| dviroel | ok, jgilaber just want to share that | 12:55 |
| dviroel | thanks | 12:55 |
| dviroel | if yo have any further comments, we can use the linked etherpad | 12:55 |
| jgilaber | #topic Still have backports open for 2025.1 | 12:55 |
| jgilaber | last week we did great progress on 2052.2, but we still have a large backlog for 2025.1 | 12:55 |
| jgilaber | #link https://review.opendev.org/q/project:openstack/watcher+branch:stable/2025.1+status:open | 12:56 |
| amoralej | i just found that setting it as implemented changes status to complete | 12:56 |
| jgilaber | no action needed here, just wanted to higlight it as a reminder | 12:56 |
| dviroel | we may get some of them until m2 if we focus on them | 12:56 |
| jgilaber | +1 | 12:56 |
| dviroel | yeah, alfredo already approved a few too, i will add to my todo list | 12:57 |
| sean-k-mooney | if you set teh implemeation feeld to done it will update the remaingin fiels | 12:57 |
| dviroel | thanks | 12:57 |
| jgilaber | moving quickly since we're almost out of time | 12:57 |
| dviroel | +1 | 12:57 |
| jgilaber | #topic reviews | 12:57 |
| sean-k-mooney | so once we are happy https://blueprints.launchpad.net/watcher/+spec/skip-actions-in-pre-condition is actully fully done which i think it is its 10 second to update that | 12:57 |
| jgilaber | I'll start with the patch series for Cinder helper migration to use openstacksdk | 12:57 |
| jgilaber | #link https://review.opendev.org/c/openstack/watcher/+/994841 | 12:57 |
| amoralej | sean-k-mooney, I just set as implemented :) | 12:58 |
| jgilaber | I pushed it today | 12:58 |
| dviroel | jgilaber: nice | 12:58 |
| sean-k-mooney | amoralej: cool | 12:58 |
| jgilaber | but I actually think we should proceed with amoralej's https://review.opendev.org/c/openstack/watcher/+/994778 first | 12:58 |
| jgilaber | they will conflict and it will be easier to rebase mine afterwards | 12:58 |
| dviroel | ack, there is a chain of patches there | 12:58 |
| amoralej | in https://review.opendev.org/c/openstack/watcher/+/994777/2?usp=related-change i'm adding some fields | 12:59 |
| amoralej | needed for zone_migration | 12:59 |
| amoralej | we have an issue with notifications https://review.opendev.org/c/openstack/watcher/+/994777/2/watcher/decision_engine/model/notification/cinder.py | 12:59 |
| amoralej | as they report volume_type as id, instead as a name, which is what we use in model | 13:00 |
| amoralej | and what api provides in volume_type | 13:00 |
| amoralej | i proposed to find name_by_id during notification handling in the api | 13:00 |
| amoralej | but i have doubts if we should add VolumeType elements in the model | 13:00 |
| amoralej | we are out of time, so we can keep discussing in the review | 13:01 |
| dviroel | it ends to be important if we really want to check constraints when migrating volume | 13:01 |
| dviroel | but we don't really do too many checks | 13:01 |
| dviroel | we may add in the future then | 13:02 |
| jgilaber | thanks amoralej | 13:02 |
| jgilaber | moving to last topic | 13:02 |
| jgilaber | #topic Volunteers to chair next meeting | 13:02 |
| jgilaber | any volunteer? | 13:02 |
| dviroel | o/ | 13:02 |
| dviroel | added my name there | 13:02 |
| dviroel | I will be out july 9th | 13:03 |
| jgilaber | thanks dviroel! and thanks all for the discussions | 13:03 |
| dviroel | so i can chair july 2nd | 13:03 |
| jgilaber | I can take the 9th, but we can discuss it next week | 13:03 |
| dviroel | thanks jgilaber++ | 13:03 |
| jgilaber | thanks all! | 13:03 |
| jgilaber | #endmeeting | 13:03 |
| opendevmeet | Meeting ended Thu Jun 25 13:03:41 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 13:03 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-06-25-12.01.html | 13:03 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-06-25-12.01.txt | 13:03 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/watcher/2026/watcher.2026-06-25-12.01.log.html | 13:03 |
| winiciusallan[m] | thanks o/ | 13:03 |
| amoralej | thanks for chairing jgilaber++ | 13:03 |
| jgilaber | https://review.opendev.org/c/opendev/irc-meetings/+/994890 is the patch to move the meeting time | 13:06 |
| jgilaber | I'm sending the ML message now | 13:06 |
| jgilaber | https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/CLQ7AEJO32LIOQIX5J4YTXVMHQECZOVZ/ | 13:09 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Add dataclass wrappers for CinderHelper API objects https://review.opendev.org/c/openstack/watcher/+/994842 | 13:09 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Replace python-cinderclient with openstacksdk https://review.opendev.org/c/openstack/watcher/+/994843 | 13:09 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove python-cinderclient dependency https://review.opendev.org/c/openstack/watcher/+/994844 | 13:09 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Use real objects in volume migration tests https://review.opendev.org/c/openstack/watcher/+/994862 | 13:09 |
| opendevreview | Merged openstack/watcher master: [ci] Increase CI jobs timeouts https://review.opendev.org/c/openstack/watcher/+/994847 | 13:23 |
| opendevreview | Merged openstack/watcher stable/2026.1: Add regression test for notification lost during synchronization https://review.opendev.org/c/openstack/watcher/+/994161 | 14:32 |
| winiciusallan[m] | jgilaber: do you know if there is a way to change the IRC file at https://meetings.opendev.org/#Watcher_Team_Meeting? | 14:46 |
| winiciusallan[m] | s/IRC/ICS | 14:50 |
| jgilaber | I'm not sure | 14:53 |
| jgilaber | it's not in the irc-meetings repo | 14:54 |
| jgilaber | maybe it's generated automatically and it needs some time? | 14:54 |
| winiciusallan[m] | probably. will check later. thanks! | 14:56 |
| dviroel | it will be updated once we update the content in irc-meeting repo | 14:58 |
| dviroel | oh, it shows 1300 already | 15:01 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Add dataclass wrappers for CinderHelper API objects https://review.opendev.org/c/openstack/watcher/+/994842 | 15:35 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Replace python-cinderclient with openstacksdk https://review.opendev.org/c/openstack/watcher/+/994843 | 15:35 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Remove python-cinderclient dependency https://review.opendev.org/c/openstack/watcher/+/994844 | 15:35 |
| opendevreview | Joan Gilabert proposed openstack/watcher master: Use real objects in volume migration tests https://review.opendev.org/c/openstack/watcher/+/994862 | 15:35 |
| opendevreview | Merged openstack/watcher stable/2026.1: Fix notification updates lost during cluster data model synchronization https://review.opendev.org/c/openstack/watcher/+/994162 | 16:20 |
| opendevreview | Merged openstack/watcher stable/2026.1: Fix LP bug link in releasenote for bug 2152645 https://review.opendev.org/c/openstack/watcher/+/994163 | 16:20 |
| sean-k-mooney | winiciusallan[m]: finally found time to do a full review of your spec | 16:33 |
| sean-k-mooney | directionally it think its good but i maed several secion inlien for how it could be updated | 16:33 |
| winiciusallan[m] | thanks sean-k-mooney | 16:34 |
| winiciusallan[m] | will check it today | 16:34 |
| opendevreview | Merged openstack/watcher-tempest-plugin master: Make test polling intervals and timeouts configurable https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/994323 | 17:55 |
| winiciusallan[m] | sean-k-mooney: about you comment regarding shelve x shelve_offload | 18:08 |
| winiciusallan[m] | i think for the purpose of the spec, it would be better if we go for shelve_offload since it frees the reserved resource | 18:09 |
| winiciusallan[m] | although we could add another action -- this might not be too much additional work | 18:10 |
| winiciusallan[m] | but i still would go with offload | 18:10 |
| sean-k-mooney | winiciusallan[m]: while there technial is an api to force the offload | 18:29 |
| sean-k-mooney | you have to first call shleve | 18:30 |
| sean-k-mooney | and then manuall call shelve offload to force it | 18:30 |
| sean-k-mooney | for this initial version we shoudl not do that | 18:30 |
| sean-k-mooney | jsut assert the vm is in the shelve or shelve offloaded state and allow nova to complete teh offload based on its configured policy | 18:30 |
| sean-k-mooney | as i said by defult it will auto trigger the offload imidealy after reaching the shelveed state | 18:31 |
| sean-k-mooney | if we wanted to have a parmater to force offload we can but that shoudl nto be the default | 18:31 |
| sean-k-mooney | it adds etra complexitity for a edge case | 18:32 |
| sean-k-mooney | that we do not expect to be common place | 18:32 |
| winiciusallan[m] | sean-k-mooney: ack. got your point | 18:47 |
| winiciusallan[m] | thank you | 18:47 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!