Earlier  
Posted Nick Remark
#openstack-nova - 2025-01-16
20:13:28 opendevreview Mengyang Zhang proposed openstack/nova master: Add Burst Length Support to Cinder QoS https://review.opendev.org/c/openstack/nova/+/939310
20:15:27 opendevreview Mengyang Zhang proposed openstack/nova master: Add Burst Length Support to Cinder QoS https://review.opendev.org/c/openstack/nova/+/939490
20:26:30 opendevreview Mengyang Zhang proposed openstack/nova-specs master: Add Burst Length Support to Cinder QoS https://review.opendev.org/c/openstack/nova-specs/+/932653
20:43:19 opendevreview Mengyang Zhang proposed openstack/nova-specs master: Add Burst Length Support to Cinder QoS https://review.opendev.org/c/openstack/nova-specs/+/932653
#openstack-nova - 2025-01-17
11:08:12 opendevreview Stephen Finucane proposed openstack/nova master: libvirt: Wrap un-proxied listDevices() and listAllDevices() https://review.opendev.org/c/openstack/nova/+/939317
13:54:48 gibi folks, what is a good way to change a multinode zuul job (nova-next) to have a different placement config than default? I cannot just set vars:devstack_local_conf as that fails as it tries to be applied on all nodes and computes has no placement service. Setting it is a group-vars that controller only does not work either as then I lose what is already set via vars.
13:54:56 gibi context https://review.opendev.org/c/openstack/nova/+/937275
13:55:48 gibi do I need to duplicate the settings from vars to group-vars?
13:56:18 dougszu Has anyone seen ephemeral volumes corrupted after a VM is migrated? I see Nova create the filesystem on the backing disk file during instance create, but then regenerate the backing disk on the destination HV. It leads to the UUID changing in the backing disk file, and the VM sees the filesystem as corrupted (for a subset of filesystems which are good spotting the anomaly).
13:56:50 dougszu *good at spotting
13:57:02 dougszu happy to create a bug and work on it, if there isn't something already
14:04:18 opendevreview Balazs Gibizer proposed openstack/nova master: [CI][nova-next]test with placement ac breadth-first https://review.opendev.org/c/openstack/nova/+/937275
14:20:29 sean-k-mooney gibi: so i can think of a few hacks but i tought we fixed this in the past
14:21:05 sean-k-mooney gibi: there was a patch propsoed before to make sure hta tbefore the post-config code ran it would do a make -p on the partent path
14:21:50 sean-k-mooney the hack is in the devstack_local_conf section you could jsut add that
14:21:59 sean-k-mooney sorry mkdir -p
14:24:57 gibi sean-k-mooney: still there is no placement.conf to edit on the computes so mkdir -p alone is not enough
14:25:21 sean-k-mooney dougszu: so nova will redownload the backing image form glance and copy it form the souce if the image is not deleted
14:25:29 sean-k-mooney *is deleted
14:25:47 sean-k-mooney gibi: the file shoudl nto be required to exist
14:25:51 sean-k-mooney it shoudl create it if its not there
14:26:13 sean-k-mooney gibi: at least that what my memory says is the expected behavior
14:26:25 sean-k-mooney im trying to find this in the devstack repo now
14:26:44 dougszu sean: what I don't see it the attempt to download the backing file - perhaps it is a misconfiguration. I've filed this with steps: https://bugs.launchpad.net/nova/+bug/2095173
14:28:09 sean-k-mooney oh sorry you mean ephmeral storage provisin via the flavor
14:28:31 sean-k-mooney so for live migration we copy the data
14:28:38 sean-k-mooney for cold migration we dont as far as i recall
14:29:17 sean-k-mooney i woudl need to check but we do not expect the content of the ephemral disks to be preseved for a number of operations
14:29:49 sean-k-mooney resize is oen of them i dont know about cold-migration. live migration is intended to preserve the data
14:30:31 dougszu Thanks - I see the ephemeral data copied for both live and cold. The bug affects both
14:31:08 sean-k-mooney so the content o fthe backing file sholud not really effect the resulting image since its ment to be blank
14:31:20 sean-k-mooney but i think i know why this is happening
14:31:54 dougszu Yeah, so I think you can configure it that way - to not create a FS on the ephemeral drive. But if you do tell Nova to create FS, it will create it on the backing file.
14:31:54 sean-k-mooney i think we are currently formating the backign file if you have not disabeld that
14:32:19 sean-k-mooney dougszu: right os we have been disucssint removign the ablity for nova to format the ephemral storage
14:32:49 sean-k-mooney we planned to disabel it by default and then deprecate it but i dont think we have doen that yet
14:33:05 sean-k-mooney for the ephmeral disk there is no backign file in glance
14:33:38 sean-k-mooney so the only optionon cold or live migrate woudl be to copy it from the souce node otherwise we would geneate a new one on the dst with no refernce to the old one a diffent uuid as a result
14:33:48 dougszu curious -yeah, that would work, it forces the FS into the top layer
14:33:54 dougszu and fixes the issue
14:34:07 dougszu but not for existing VMs :D
14:34:23 gibi sean-k-mooney: so you suggest that devstack_local_conf post-config should work even if the referenced service is not deployed and the config file is not there as it i) creates the missing dir ii) generates a new file with the post-config content if the file does not exits?
14:34:27 sean-k-mooney right so evernayully we also dont want to have backign files for test disks ata ll
14:34:52 sean-k-mooney the fact they have them is a sideffect of hwo the qcow dirver is currently impelmetned and not really intentional
14:35:17 sean-k-mooney gibi: that is how i think it was orgianly inteded to work yes
14:35:33 sean-k-mooney or at least that is how i would have implemtned it
14:35:47 dougszu You also can't copy the backing file from the source node. Eg. if you had two identical VMs on different HVs, and migrated them both to another HV, they would fight over the backing file.
14:36:08 sean-k-mooney dougszu: you can but you need ot have a diffent name for it
14:36:20 gibi sean-k-mooney: ack, I can also try to dig devstack...
14:36:25 gibi based on thsi
14:36:27 gibi this
14:37:06 dougszu yeah - agree on that - different name would work
14:37:21 sean-k-mooney dougszu: but ya we dont generate a repoducable file system on the ephmale backign file today as far as im aware.
14:37:32 sean-k-mooney i agree this is a bug of some kind
14:37:50 sean-k-mooney its not clear to me what the best path forward is in ths short term
14:38:08 sean-k-mooney long terme there shoudl be no backing file and or no data in the backing file
14:38:24 dougszu thanks Sean, that's all helpful. I think as you say, the easiest fix is to just not support created the FS on the backing file
14:38:32 dougszu *creating
14:39:18 dougszu I will have a think about a fix for existing VMs. I think you can rebase the top layer onto a new backing file for one.
14:39:20 sean-k-mooney we wanted to make that change to reduce the security footprint of nova
14:39:56 sean-k-mooney dougszu: we might be abel to flatten the image on migration, im not sure
14:40:03 dougszu It also avoids issues with for example Nova making a v5 XFS FS and then booting a C7.9 image with XFS 4 support etc
14:40:50 dougszu yeah, flatten is also interesting
14:44:52 sean-k-mooney so i think this bug is another reaons to implement https://blueprints.launchpad.net/nova/+spec/default-ephemeral-format-unformated sooner rather then later
14:45:07 sean-k-mooney i cant commit to doing that this cycle but i might see if i can find time to try
14:49:16 dougszu ^ that looks good. I'd be happy to test/review/help out.
14:50:30 sean-k-mooney gibi: i think this is the relevent fucntion https://github.com/openstack/devstack/blob/38f8f4da4556c11bf526392359ed6c14b45d87ea/inc/meta-config#L79
14:52:22 gibi sean-k-mooney: thanks!
14:53:09 sean-k-mooney the comment says it shoudl create the file if it does not exist which is the behviaor i recall i think its just failing because /etc/placement is not there for it to create the file under hence the mkdir -p comment
14:55:37 gibi OK I will dig
14:58:54 opendevreview Dan Smith proposed openstack/nova master: Handle GPT image detection https://review.opendev.org/c/openstack/nova/+/933928
14:58:55 opendevreview Dan Smith proposed openstack/nova master: DNM: Test with latest oslo.utils https://review.opendev.org/c/openstack/nova/+/933444
15:01:27 sean-k-mooney gibi: found it https://review.opendev.org/c/openstack/devstack/+/922846
15:01:53 sean-k-mooney gibi: i know i debugged that at some point before
15:02:00 sean-k-mooney *knew
15:06:43 gibi sean-k-mooney: awesome, I will put a depends-on on it to see if this helps.
15:07:10 gibi sean-k-mooney: also an easy win review about whitebox in periodic queue https://review.opendev.org/c/openstack/nova/+/833453
15:08:15 sean-k-mooney oh cool artom updated that
15:08:39 sean-k-mooney done
15:08:55 sean-k-mooney we can review it for stablity i guess and see how it goes
15:10:51 gibi yepp, bauzas tend to check the periodic state during our weekly meeting so we will see
15:11:06 sean-k-mooney speakign of easy wins im also approving https://review.opendev.org/c/openstack/nova/+/939453/1 to disable the heal perodic in nova-next
15:11:23 sean-k-mooney when you have time https://review.opendev.org/c/openstack/nova/+/939476 is the follow up about changing the default
15:11:49 sean-k-mooney i was going to add that to next weeks team meeting ot get import
15:25:53 gibi ack
15:57:24 dansmith ugh.. this is wrong: https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.snapshot_image_format
15:58:01 dansmith the default is not "the same type as source image" it's "same type as the ephemeral backend is using"
15:59:27 opendevreview Balazs Gibizer proposed openstack/nova master: [CI][nova-next]test with placement ac breadth-first https://review.opendev.org/c/openstack/nova/+/937275
16:31:21 sean-k-mooney dansmith: i have not at the code but perhaps "souce iamge" in this context was inteded to refer to "the format fo the file on disk that was snapshoted" rather then glance
16:31:33 sean-k-mooney which would match what you are stating
16:31:49 dansmith well, that's what the code is doing, but I don't think that's how someone would read that doc text
16:33:05 dansmith glance people also had assumed that nova snapshotted in the format of the original (source glance) image
16:33:14 sean-k-mooney ya without reading the docs i woudl have assuemd nova woudl use the same format in glance as the image was on disk but iagree that not what i would take away form that text
16:34:07 sean-k-mooney well novas current behaivor is not really surpsing to me nessisarly
16:34:30 sean-k-mooney but i agree the docs are incorrect
16:35:02 dansmith it's not really surprising to me either knowing the code and how things work under the covers, I just think that's not what the reader of the doc would think
16:35:24 sean-k-mooney this is also kind of glossing over images_type=rbd
16:35:29 dansmith and so when it was asserted that the format would be the same as the source (glance image) and I read that doc, I assumed that's what we were doing
16:35:35 dansmith yeah, also that
16:36:13 sean-k-mooney do you know what happens if you set this and you use images_type=rbd ?

Earlier   Later