| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-07-25 | |||
| 10:58:45 | noonedeadpunk | ++ fair enough | |
| 10:58:47 | sean-k-mooney | noonedeadpunk: nova has logic to do a cinder volume snapshot if it BFV | |
| 10:58:59 | noonedeadpunk | oh... | |
| 10:59:03 | noonedeadpunk | I missed that entirely | |
| 10:59:11 | sean-k-mooney | we still upload an empty glance iamge to hold metadata | |
| 10:59:22 | sean-k-mooney | but it just point to the cinder snapshot | |
| 11:00:10 | sean-k-mooney | we also have an addtion gem | |
| 11:00:26 | noonedeadpunk | but it's kinda... not very user frioendly? in terms of - you need to spawn snapshot in one specific way rather then other to be able to restore later? | |
| 11:00:41 | sean-k-mooney | if you have a BFV guest and it has addtional cidner data volume io belive a nova snapshot will snapshot all the disks | |
| 11:00:50 | sean-k-mooney | although i could be miss remeberting | |
| 11:01:06 | noonedeadpunk | anyway.... | |
| 11:01:15 | noonedeadpunk | this is really very different topic | |
| 11:01:42 | sean-k-mooney | noonedeadpunk: no when they do rebuild it just updates the root disk, they can resotre the other volumes via cinder too indepently | |
| 11:01:49 | noonedeadpunk | I guess I wanted just to help out with the process of how one could work collaboratively on other patch | |
| 11:01:59 | sean-k-mooney | noonedeadpunk: whihc you did | |
| 11:02:45 | sean-k-mooney | they 5 year old patch they found might be useful fo rother backends | |
| 11:03:10 | noonedeadpunk | sean-k-mooney: frankly - I feel this being very confusing. And still not covering cinder-backups for root volumes... | |
| 11:03:43 | sean-k-mooney | i belive you can just use cidner to do ther backups for a root volume | |
| 11:03:53 | sean-k-mooney | the only part you cant do that way i belive is the restore | |
| 11:03:58 | noonedeadpunk | you just can't recover without destroying the instance, yeah | |
| 11:04:46 | sean-k-mooney | the way to fix that would be to make 2 changes | |
| 11:05:11 | sean-k-mooney | well kind of 1 | |
| 11:05:23 | sean-k-mooney | when you shleve an instance the volume should move to the reserved state | |
| 11:05:29 | sean-k-mooney | once the instnace is shleve offloaded | |
| 11:05:46 | sean-k-mooney | if cidner allowed you to restore in the reserved state then you coudl do it via cidner api | |
| 11:05:57 | noonedeadpunk | I think last time discussed the problem was on how/where to store attachment order or smth like that | |
| 11:06:22 | sean-k-mooney | i said 2 becaue it might be valid to consier putting the volume in reserved after stop | |
| 11:06:25 | noonedeadpunk | but now.. .I'm not sure if you also have to get it detached... | |
| 11:06:42 | noonedeadpunk | yeah. that might be actually a good point... | |
| 11:06:53 | sean-k-mooney | and then allow you to restore when its stopped or change the rebuild api to optionally take a volume snapshot uuid instead of an image | |
| 11:07:50 | noonedeadpunk | well, I think you should be then able also to revert the snapshot with cinder api when it's shelved | |
| 11:08:09 | noonedeadpunk | as I think it's almost the same check for restore snapshot/backup | |
| 11:08:10 | sean-k-mooney | i think right now cidner need it ot be in aviable state | |
| 11:08:16 | sean-k-mooney | rather then reserved | |
| 11:08:21 | noonedeadpunk | right | |
| 11:08:25 | sean-k-mooney | i think that the limiitation | |
| 11:09:21 | sean-k-mooney | its alwasy been a bit fo a rough spot | |
| 11:10:21 | sean-k-mooney | i was not as apposed to the idea of detaching the root volume as other were although i htink that only realy make sense in a shelved like state | |
| 11:11:02 | noonedeadpunk | yes, totally, it should be shelved. Though indeed detaching makes complicated reverse order of attach | |
| 11:11:14 | noonedeadpunk | and reserved state sounds indeed more prespective... | |
| 11:12:24 | sean-k-mooney | one thing i wish we had a better way of supproting in nova is virual media, i wish we had a simple way to attach iso at runtime. currently you can pass the disk type when you attach a cinder voluem outside of server create | |
| 11:12:59 | sean-k-mooney | so while you can create a volume form an iso and attaach it to a vm it will be attached as a block device | |
| 11:13:52 | sean-k-mooney | rescue has alwasy been the hack but it woudl have been nice if nova coudl supprot boot over http or pxe or other metod that were less reliant on glance for metadta storage | |
| 11:14:31 | sean-k-mooney | we are seeing pain point aroudn that for folks wanting to bring a bunch of pet form vmware or other cloud over to openstack | |
| 11:15:14 | sean-k-mooney | i.e. the dont nessiarly want to create a glance image and delete it for every vm but also dont nessiarly want to have to use a volume either | |
| 11:16:46 | sean-k-mooney | so part of me wishes nova supprot takeing a http/ftp path to a disk image and usign that. or coudl attatch addtional disk after boot form glance or swift or elsewhere | |
| 11:17:15 | sean-k-mooney | beign able to detach and or replace the root disk woudl be a natural extention of that | |
| 11:17:24 | noonedeadpunk | that sounds like smth that potentiallly could posses a security concern in the fuiture | |
| 11:17:40 | noonedeadpunk | in terms of http/ftp | |
| 11:17:43 | sean-k-mooney | no downloading random things form the internet :P | |
| 11:17:46 | sean-k-mooney | how | |
| 11:18:00 | sean-k-mooney | but ya the thing is that nova cant trust glance to do the right thing | |
| 11:18:07 | sean-k-mooney | it has to do the security checks itself | |
| 11:18:08 | noonedeadpunk | well exactly - how to limit downloading random thing from the internet :) | |
| 11:18:12 | sean-k-mooney | so your right | |
| 11:18:20 | noonedeadpunk | like glance web-download already scares me enough from time to time | |
| 11:18:34 | sean-k-mooney | well it basiclly woudl be that | |
| 11:18:48 | sean-k-mooney | glance supprot referencig an image on an external web sever | |
| 11:19:03 | sean-k-mooney | im just talkign about the same capablity in nova directly | |
| 11:19:24 | noonedeadpunk | but also creating a voilume from iso usually kinda works for vmware migrations.... or rescue at worst... | |
| 11:19:58 | noonedeadpunk | well in Glance one can disable that quite easily, just to mention that | |
| 11:20:22 | sean-k-mooney | ya so at server create you can annotat the volume as being an iso or rather disk_type=cdrom | |
| 11:20:38 | sean-k-mooney | we just dont expost that filed form the bdm on volume attach and we shoudl | |
| 11:20:48 | sean-k-mooney | there are other disk types like lun | |
| 11:21:05 | noonedeadpunk | but actually - that is kinda a good point, of why multiple volumes can't be attached on boot... | |
| 11:21:07 | sean-k-mooney | which can ony be set on boot too that are needed for scsi v3 command instead of scsi v2 | |
| 11:21:21 | sean-k-mooney | you can have multipel volumes | |
| 11:21:58 | sean-k-mooney | so you can have the root be a image or a volume and you can have arbitry number of addtional cinder data volumes | |
| 11:22:14 | noonedeadpunk | ah, indeed, you can pass block_device_mapping_v2 | |
| 11:22:16 | sean-k-mooney | that what peole do when migrating they create 1 volume per disk in vmware | |
| 11:22:44 | sean-k-mooney | noonedeadpunk: yep but even without that you can use the syntatic sugar commadn in osc | |
| 11:22:55 | sean-k-mooney | you just repeate --volume for each addtional volume | |
| 11:24:26 | sean-k-mooney | osc will internally comptue the block_device_mapping_v2 object for you, that what it alwasy doing when you use volumes internally | |
| 11:25:07 | sean-k-mooney | the issue with the attach api is we only expose some of the filed setable via BDMv2 structure | |
| 11:25:52 | sean-k-mooney | so nova hwas the ablity at server create to create more complex topolgies then you can create post boot via attach | |
| 12:02:20 | opendevreview | Balazs Gibizer proposed openstack/nova master: Print ThreadPool statistics https://review.opendev.org/c/openstack/nova/+/948340 | |
| 12:02:21 | opendevreview | Balazs Gibizer proposed openstack/nova master: Allow services to start with threading https://review.opendev.org/c/openstack/nova/+/948311 | |
| 12:02:21 | opendevreview | Balazs Gibizer proposed openstack/nova master: Document native threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364 | |
| 12:02:22 | opendevreview | Balazs Gibizer proposed openstack/nova master: Do not yield in threading mode https://review.opendev.org/c/openstack/nova/+/950994 | |
| 12:02:22 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450 | |
| 12:02:23 | opendevreview | Balazs Gibizer proposed openstack/nova master: Allow to start unit test without eventlet https://review.opendev.org/c/openstack/nova/+/953436 | |
| 12:02:23 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-api and -metadata in threaded mode https://review.opendev.org/c/openstack/nova/+/951957 | |
| 12:02:24 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run unit test with threading mode https://review.opendev.org/c/openstack/nova/+/953475 | |
| 12:02:25 | opendevreview | Balazs Gibizer proposed openstack/nova master: [CI]Make nova-tox-py312-threading voting https://review.opendev.org/c/openstack/nova/+/955791 | |
| 12:02:25 | opendevreview | Balazs Gibizer proposed openstack/nova master: [test]RPC using threading or eventlet selectively https://review.opendev.org/c/openstack/nova/+/953815 | |
| 12:02:27 | opendevreview | Balazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor https://review.opendev.org/c/openstack/nova/+/952666 | |
| 13:51:05 | opendevreview | Balazs Gibizer proposed openstack/nova master: [test]Speed up fs retry tests by mocking sleep https://review.opendev.org/c/openstack/nova/+/955904 | |
| 13:51:06 | opendevreview | Balazs Gibizer proposed openstack/nova master: [test]Speed up RBD test by decreasing retry interval https://review.opendev.org/c/openstack/nova/+/955906 | |
| 13:51:06 | opendevreview | Balazs Gibizer proposed openstack/nova master: [test]Speed up ironic console test by decreasing timeout https://review.opendev.org/c/openstack/nova/+/955905 | |
| 13:51:07 | opendevreview | Balazs Gibizer proposed openstack/nova master: [test]Speed up qemu announce test by mocking sleep https://review.opendev.org/c/openstack/nova/+/955907 | |
| 13:51:42 | gibi | I have to run a lot of unittest lately so I use a bit of time to speed them up ^^ https://review.opendev.org/c/openstack/nova/+/955907 | |
| 13:51:56 | gibi | wong link, I wanted to point to the topic https://review.opendev.org/q/topic:%22unit-test-speedup%22 | |
| 13:52:43 | gibi | these are very small unit test only patches for easy wins | |
| 13:56:01 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova-specs master: Propose enabling parallel live migrations for libvirt https://review.opendev.org/c/openstack/nova-specs/+/955783 | |
| 14:27:58 | noonedeadpunk | um... what the broken crap is `autopep8`? | |
| 14:29:07 | noonedeadpunk | this is pretty much ridiculous: https://zuul.opendev.org/t/openstack/build/b483760112414b64b045615b76bde314 | |
| 14:33:39 | noonedeadpunk | ah, so it tried to handle >80 this wayu, lol | |
| 14:33:59 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova master: [WIP] Allow to perform parallel live migrations https://review.opendev.org/c/openstack/nova/+/955784 | |
| 15:07:39 | opendevreview | Balazs Gibizer proposed openstack/nova master: Document native threading mode and tuneables https://review.opendev.org/c/openstack/nova/+/949364 | |
| 15:07:39 | opendevreview | Balazs Gibizer proposed openstack/nova master: Print ThreadPool statistics https://review.opendev.org/c/openstack/nova/+/948340 | |