| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-25 | |||
| 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 | |
| 00:29:26 | melwitt | oh. I guess you could do that | |
| 00:30:59 | sean-k-mooney[m] | https://dev.mysql.com/doc/refman/8.4/en/group-replication-system-variables.html#sysvar_group_replication_transaction_size_limit | |
| 00:31:19 | sean-k-mooney[m] | melwitt that could be a future thing | |
| 00:31:28 | melwitt | I feel like that would be a separate thing where if we did it we would change archive to work the same way, at the same time. I think they should be consistent. | |
| 00:31:31 | sean-k-mooney[m] | the fact you providing a default kind of paper over the problem | |
| 00:32:06 | sean-k-mooney[m] | ya im not going to ask you to put it in the current patch fro that reason | |
| 00:32:14 | melwitt | and this patch is addressing the fact that today, if your shadow tables are too large, you are just screwed and you can't purge them with nova tooling and you have to truncate them manually | |
| 00:32:19 | sean-k-mooney[m] | i just wanted to raise that design point | |
| 00:32:36 | melwitt | fair enough :) | |
| 00:33:11 | sean-k-mooney[m] | yep so personally i think we should be deprecating the nova tooling and saying you should use some fo the external toolign for this | |
| 00:33:24 | sean-k-mooney[m] | but i know that wont happen any time soon | |
| 00:34:03 | melwitt | I think people might find that harsh. what kind of external tooling are you thinking of? | |
| 00:36:51 | sean-k-mooney[m] | there are two diffent set of tooling | |
| 00:37:22 | sean-k-mooney[m] | there is a tool that manages archiveing and purging records for all service in a common way inculdiign for serice that dont have shadow tables | |
| 00:38:04 | sean-k-mooney[m] | ill see if i can find the link but it handels nova neuron ectar all the same way with the ablity to archive them to a diffent database service instance or locally to files | |
| 00:38:13 | melwitt | oh, right, that does sound familiar | |
| 00:38:21 | sean-k-mooney[m] | there si allso osops tools which has a nova specifc srcipt https://opendev.org/openstack/osops/src/branch/master/tools/generic/nova/openstack_db_archive.sh | |
| 00:39:26 | melwitt | yeah, I see what you mean now. I agree I think that would be ideal for there to be a unified thing that will work for all of the projects | |
| 00:39:59 | melwitt | when you said "external" I thought you meant external to openstack and was confused | |
| 00:41:22 | sean-k-mooney[m] | https://github.com/ovh/osarchiver | |
| 00:41:34 | sean-k-mooney[m] | well i was thinking of ^ | |
| 00:41:56 | sean-k-mooney[m] | thats the thing that basicaly does this for all proejcts in a consistent way | |
| 00:42:08 | melwitt | oh, interesting | |
| 00:42:59 | sean-k-mooney[m] | it basically does not use shadowtable at all | |
| 00:43:20 | sean-k-mooney[m] | it can arcive without deletign or it can archive and delete the rows in teh service dbs | |
| 00:43:27 | sean-k-mooney[m] | to get a similar effect | |
| 00:44:12 | sean-k-mooney[m] | given you can restore thing from the shadown tabels to the main tables i would actully say its more usefual because it mvoes the data to an entirly differnt db in teh same format | |
| 00:44:29 | sean-k-mooney[m] | which is you ever wanted to restore those rows back for any reason would be simpler | |
| 00:45:11 | sean-k-mooney[m] | its like doing incremental backups of only the rows marked as deleted | |
| 00:45:40 | sean-k-mooney[m] | the reason osarchiver is not hosted in opendev is because we didnt agree which repo to put it in | |
| 00:45:45 | sean-k-mooney[m] | which is a shame | |
| 00:45:50 | melwitt | yeah, I was just thinking that if people kept incremental backups there would be no use for shadow tables | |
| 00:46:14 | melwitt | hah, nice | |
| 00:46:53 | sean-k-mooney[m] | there was a maining list tread about it like 4 years ago i belvie and it just stalled out | |
| 00:47:29 | melwitt | reposhed | |
| 00:47:59 | sean-k-mooney[m] | melwitt: anyway i think that a better technial solution i just dont think we will ever get to that at least not unless something changes | |
| 00:48:29 | sean-k-mooney[m] | i wanted to use that in our new installer but…. it was too much effort to advocate for that and get by in | |
| 00:49:23 | melwitt | yeah. especially difficult if it's not in opendev | |
| 00:50:02 | sean-k-mooney[m] | it was more that pm didnt want use to focus on day two operations like automating backups of db in the operators | |
| 00:51:04 | sean-k-mooney[m] | so providing incremental backups and “archiving” of this in a centralised way was not a priority | |