| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-25 | |||
| 16:53:05 | MengyangZhang[m] | yes | |
| 16:53:08 | bauzas | https://review.opendev.org/c/openstack/nova-specs/+/932653 | |
| 16:53:42 | bauzas | seems to me a design question | |
| 16:53:53 | bauzas | could we just do this in the gerrit change review ? | |
| 16:54:11 | bauzas | do we need a quorum consensus ? | |
| 16:55:58 | MengyangZhang[m] | besides that min version check question, also need review and approval of the spec to move forward | |
| 16:56:29 | bauzas | MengyangZhang[m]: that's our usual review cycle | |
| 16:56:44 | bauzas | but for the moment, even 2025.2 work hasn't started | |
| 16:56:59 | bauzas | so please understand that people have other priorities for now | |
| 16:57:34 | bauzas | MengyangZhang[m]: the best if you want is to have a cross-project discussion with the cinder folks at the PTG | |
| 16:57:46 | sean-k-mooney | bauzas: context for this | |
| 16:57:50 | bauzas | that would I guess answer most of the design questions, and it would be quick | |
| 16:58:01 | MengyangZhang[m] | understood, meanwhile can I have some clarity on that design question? I may shift my focus to other projects in my company and won't be able to follow this until q2 | |
| 16:58:06 | sean-k-mooney | i was orginally asking that we have a min version ceck to know that the compute node can supprot the new frontend qos option | |
| 16:58:24 | sean-k-mooney | it turns out that cinder allows you to update the qos on a volume type | |
| 16:58:28 | bauzas | sean-k-mooney: that's the usual upgrade pattern yeah | |
| 16:58:37 | sean-k-mooney | and it will take effect to all volumes of that type | |
| 16:58:42 | sean-k-mooney | on the next move op | |
| 16:58:50 | sean-k-mooney | or when we next update the attachment | |
| 16:59:06 | bauzas | so even old computes would see it ? | |
| 16:59:07 | sean-k-mooney | so cinder is not caching it liek we do with the falvor/image properties when the volume is created | |
| 16:59:10 | sean-k-mooney | yep | |
| 16:59:21 | sean-k-mooney | so this is a pre exisitng upgrade problem | |
| 16:59:24 | bauzas | that's an harder upgrade pattern to solve | |
| 16:59:30 | bauzas | yeah, sounds | |
| 16:59:43 | bauzas | like, someone has to do a pre-upgrade flight | |
| 16:59:43 | sean-k-mooney | so i dont think we can actully really protect agaisnt this in nova | |
| 17:00:04 | bauzas | we could say 'unsupported until all your computes are upgraded' | |
| 17:00:06 | sean-k-mooney | anyway we shoudl dicuss more with the cinder folks | |
| 17:00:32 | sean-k-mooney | but we cant just enforce "not supported until all upgraded" in our code just in docs | |
| 17:00:33 | bauzas | is there any API impact? tbh I haven't reviewed the spec | |
| 17:00:39 | bauzas | hah | |
| 17:01:00 | bauzas | sounds to me then a perfect cinder-nova PTG discussion | |
| 17:01:13 | bauzas | MengyangZhang[m]: could you join the PTG ? | |
| 17:01:29 | bauzas | anyway, we're on time | |
| 17:01:35 | bauzas | thanks all | |
| 17:01:39 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.log.html | |
| 17:01:39 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.txt | |
| 17:01:39 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.html | |
| 17:01:39 | opendevmeet | Meeting ended Tue Feb 25 17:01:39 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:39 | bauzas | #endmeeting | |
| 17:01:45 | MengyangZhang[m] | sure, do i need to register for the event? You mean the one from April 7-11, right? Let me know what I need to do | |
| 17:02:04 | MengyangZhang[m] | sorry would be my first time joining | |
| 17:02:40 | sean-k-mooney | bauzas: no api impact on our side or cinders becuase they dont version this part of the api | |
| 17:03:17 | sean-k-mooney | althogh that coudl depend on the ptg dicussion | |
| 17:03:25 | bauzas | sean-k-mooney: I definitely need to review the spec then | |
| 17:03:34 | sean-k-mooney | one topic MengyangZhang[m] was interested in was a way to refesh the qos on a volume live | |
| 17:03:37 | fwiesel | Thanks everyone | |
| 17:03:40 | sean-k-mooney | that woul likely need a new instance action | |
| 17:03:48 | bauzas | wow | |
| 17:03:54 | sean-k-mooney | but i dont think that is in the spec | |
| 17:04:04 | bauzas | 'taint my instance' | |
| 17:04:06 | sean-k-mooney | bauzas: libvirt supprot updatign them | |
| 17:04:12 | sean-k-mooney | we just dont | |
| 17:04:15 | bauzas | libvirt can do many things we don't | |
| 17:04:19 | MengyangZhang[m] | it's a separate bp and doesn;t have a spec yet | |
| 17:04:37 | bauzas | this doesn't mean that we should wrap all libvirt things | |
| 17:04:52 | sean-k-mooney | bauzas: its basically asking us to sync nova state with cidner state since it allows it to change without our say so | |
| 17:04:54 | bauzas | we're a cloud API, libvirt is an hypervisor | |
| 17:05:05 | bauzas | diffreent usecases | |
| 17:05:22 | sean-k-mooney | bauzas: today it gets updated on live migration... | |
| 17:05:41 | sean-k-mooney | so you update it in cinder and the new atachment used for live migation will get the new qos... | |
| 17:06:14 | sean-k-mooney | nova does not offically supprot that | |
| 17:06:26 | sean-k-mooney | i personally consier that a but but its apprely what happens today | |
| 17:06:27 | bauzas | we had events for cross-project communication, right? | |
| 17:06:36 | sean-k-mooney | we do it does nto use that | |
| 17:06:45 | sean-k-mooney | its because we only use those event on the volume | |
| 17:06:53 | sean-k-mooney | where as they are chging the qos on teh voluem type | |
| 17:06:58 | bauzas | anyway, looks we definitely need to design it at the PTG | |
| 17:07:09 | sean-k-mooney | basiclly they are updating there version fo a flavor and applying it to all instnaces | |
| 17:07:16 | bauzas | and I need to leave now, python meeting downtown | |
| 17:07:29 | sean-k-mooney | o/ | |
| 17:09:11 | MengyangZhang[m] | thanks for all the discussion. sounds like we will continue this in PTG, let me know how to register it coz I think it already passed the registration deadline of Feb 21, no? | |
| 17:12:18 | MengyangZhang[m] | Oh i think i managed to register on openinfra site | |
| 17:16:07 | opendevreview | Stefan Hoffmann proposed openstack/os-vif master: [ovs] Add method to get external_ids from Interface https://review.opendev.org/c/openstack/os-vif/+/942715 | |
| 17:35:32 | vsaienko | hello nova team, please add to your review queue. Fixes non working ironic serial console https://review.opendev.org/c/openstack/nova/+/942575 | |
| 17:35:44 | vsaienko | already has +1 from Ironic folks | |
| 17:39:16 | JayF | and I think we should be able to backport it given the osdk fix is backporting, too | |
| 19:07:09 | opendevreview | Douglas Viroel proposed openstack/nova master: Add support for showing scheduler_hints in server details https://review.opendev.org/c/openstack/nova/+/938604 | |
| 19:09:32 | mikal | Morning | |
| 19:16:54 | opendevreview | Merged openstack/nova master: Per-Property ImageMetaPropsWeigher https://review.opendev.org/c/openstack/nova/+/941601 | |
| 20:07:24 | opendevreview | Douglas Viroel proposed openstack/nova master: DNM - Testing microversion 2.100 changes https://review.opendev.org/c/openstack/nova/+/942728 | |
| 21:25:03 | opendevreview | Alan Bishop proposed openstack/nova master: Show swap_progress in attachment details https://review.opendev.org/c/openstack/nova/+/941476 | |
| #openstack-nova - 2025-02-26 | |||
| 00:16:07 | sean-k-mooney[m] | bauzas: can you review this in your morning and the repoducer patch above it https://review.opendev.org/c/openstack/nova/+/932931/2 i would like to make sure thats included in epoxy so we can start backporting it to stable ideally beforee bobcat goes eol. | |
| 00:17:30 | opendevreview | melanie witt proposed openstack/nova master: nova-manage: Add --max-rows option to 'db purge' command https://review.opendev.org/c/openstack/nova/+/927339 | |
| 00:19:57 | sean-k-mooney[m] | so i think that is related to a donwstream bug report right ^ should the user really have to pass —max rows or should nova just do it in bataches automatically | |
| 00:21:41 | melwitt | sean-k-mooney: it is related to a downstream bug report but the bug reporter noted that what we need is the same ability we have for archive_deleted_rows (which allows someone to control what size they want the batches to be). --max-rows defaults to 1000 | |
| 00:24:51 | sean-k-mooney[m] | i commented on the review as well but ya i noticed that defaulting when i looked more closely | |
| 00:25:30 | sean-k-mooney[m] | i guess that kind of indirectly does what i asked for so im ok with that i think | |
| 00:26:16 | sean-k-mooney[m] | basiclly it would be good for nova to hide this impelation detail form the user. its unlikely that archiveing 1000 instance would exceeed the transaction limit size | |
| 00:26:27 | sean-k-mooney[m] | posible but unlikely | |
| 00:26:40 | sean-k-mooney[m] | * purgeing not archiveing | |
| 00:27:25 | sean-k-mooney[m] | to me the fact a transaction size limit is a internal detail that a user of nova manage should ideallly not need to care about | |
| 00:27:26 | melwitt | fwiw the database transaction limit and packet size etc is all configurable on the database side so it's not something you can assume | |
| 00:27:46 | sean-k-mooney[m] | right but it is something we can look up | |
| 00:27:54 | melwitt | in my experience, operators do like to tune this to how they want, so I haven't thought about hiding bc of that | |
| 00:28:40 | sean-k-mooney[m] | im still of the opion that nova should not have shadow tables and archiving should be done externally to noav using other tooling :) | |
| 00:28:49 | melwitt | not really because we can't go looking into their innodb config or whatever | |
| 00:29:11 | sean-k-mooney[m] | you can make an sql query to look it up i touhgt | |
| 00:29:22 | sean-k-mooney[m] | the same way you can do that to get the connection limit | |