| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-22 | |||
| 16:03:42 | melwitt | yes it does | |
| 16:04:11 | sean-k-mooney | so when i was looking at the snapshot code i think i say we shoudl usjt update it to be qcow | |
| 16:04:19 | melwitt | but on our side we store the volume attachment connection_info and the format captured there represents the format of the volume (which is raw) not the snapshot (which is qcow2) | |
| 16:04:58 | sean-k-mooney | ya | |
| 16:05:03 | melwitt | yeah, the thing is how to "remember" that when the instance is rebooted for example | |
| 16:05:50 | sean-k-mooney | let me see if i can find the code i was suggesting changing but basicaly i was suggestin updating the format on the image | |
| 16:06:07 | sean-k-mooney | what your dowing sound valid | |
| 16:06:13 | sean-k-mooney | just not sure if its requried | |
| 16:06:18 | melwitt | oh, hm | |
| 16:07:54 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2932-L2958 | |
| 16:08:00 | sean-k-mooney | i tought we could fix that in that code | |
| 16:09:04 | melwitt | ok, I will look at that. thanks for the pointer | |
| 16:10:16 | sean-k-mooney | honestly i think when we create teh snapshot the connection info should get updated to qcow | |
| 16:11:11 | melwitt | sean-k-mooney: I tried that first https://review.opendev.org/c/openstack/cinder/+/857528 and it's run into problems | |
| 16:11:32 | melwitt | if you have any thoughts on that one as well | |
| 16:12:06 | sean-k-mooney | well the backend driver should be reprotign it as qcow no? | |
| 16:12:14 | melwitt | because unless the connection_info gets updated in cinder, we will overwrite it when we do refresh connection_info | |
| 16:12:23 | sean-k-mooney | like its a bug for them to be returnign raw after the snapshot is created | |
| 16:12:33 | melwitt | cinder only keeps the volume format, not the snapshot format | |
| 16:12:46 | melwitt | that's the only thing it knows how to return | |
| 16:13:10 | sean-k-mooney | right so the volume format should be updated once we snapshot right | |
| 16:13:19 | sean-k-mooney | because it has now changed | |
| 16:13:30 | melwitt | yeah, so I tried that and it broke volume extend | |
| 16:13:35 | sean-k-mooney | fun | |
| 16:13:53 | melwitt | because the resize needs to change the size of the raw backing file iiuc | |
| 16:14:05 | sean-k-mooney | so we could work around this in nova but i think we shoudl also bring this up with cinder in the ptg | |
| 16:14:13 | melwitt | so if we stored qcow2, that blows up when it tries to resize raw by specifying qcow2 | |
| 16:14:22 | sean-k-mooney | well extend is not supported with nfs | |
| 16:14:28 | sean-k-mooney | so that shoudl not be a problem | |
| 16:14:29 | melwitt | it is | |
| 16:14:31 | sean-k-mooney | its not | |
| 16:14:42 | sean-k-mooney | we have a spec and open bug for it | |
| 16:14:46 | melwitt | it's in the nfs job, that's how I know it failed :P | |
| 16:14:56 | sean-k-mooney | well its not supported | |
| 16:15:06 | melwitt | ? | |
| 16:15:11 | sean-k-mooney | https://bugs.launchpad.net/cinder/+bug/1870367 | |
| 16:15:52 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/855490 | |
| 16:16:03 | sean-k-mooney | that is the spec to add extend support in A | |
| 16:16:54 | melwitt | huh. | |
| 16:17:03 | melwitt | I wonder what/how it's running the tests on nfs and passing currently | |
| 16:17:23 | sean-k-mooney | it can work but i think its racy | |
| 16:17:31 | melwitt | ugh, ok. | |
| 16:17:35 | sean-k-mooney | basicaly they tought they fixed it | |
| 16:17:46 | sean-k-mooney | but the external event is async | |
| 16:17:56 | sean-k-mooney | so there is no way for cidner ot know if it works or not | |
| 16:18:25 | sean-k-mooney | there is also https://bugs.launchpad.net/cinder/+bug/1978294 | |
| 16:19:51 | melwitt | yeah.. I have seen that but I didn't remember it when I saw the extend test fail | |
| 16:21:03 | melwitt | I'll add something to the ptg agenda about this | |
| 16:22:06 | melwitt | bc even if we skipped the extend tests for nfs, changing the actual volume format in the metadata to qcow2 afaik isn't correct because it's the snapshot that is qcow2 and the volume itself is still raw. so we're still stuck | |
| 16:33:09 | stephenfin | melwitt: Random question. It appears the '<class>' argument to 'nova quota-class-show <class>' doesn't do anything. Is that expected? | |
| 16:34:14 | sean-k-mooney | melwitt: see the way this works with nfs that is not reallly true | |
| 16:34:22 | melwitt | stephenfin: I don't think that's expected. are you running like 'nova quota-class-show default'? | |
| 16:34:52 | sean-k-mooney | when we create the snapshot the snapshot point to the orginal file and the vm is now runnign form the qcow that is created on top right | |
| 16:35:02 | melwitt | stephenfin: bc default is the only quota class that automatically exists, any others have to be created by the admin user | |
| 16:35:02 | gibi | gmann, stephenfin: sorry I focused elsewhere. I see stephenfin approved it now | |
| 16:35:16 | melwitt | sean-k-mooney: yes right | |
| 16:35:17 | sean-k-mooney | so the snapshot is actully raw and the volume is now qcow? | |
| 16:35:52 | stephenfin | https://paste.opendev.org/show/bUrfKrK6aKCSbqfRJzNZ/ | |
| 16:35:54 | sean-k-mooney | so its the revers of what i sugeste orginally the snapshot remaisn the same but the volume format changes | |
| 16:35:55 | stephenfin | melwitt: ^ | |
| 16:37:05 | sean-k-mooney | stephenfin: why are you using 2.1 | |
| 16:37:21 | stephenfin | to make sure we hadn't broken things in a newer microversion | |
| 16:37:23 | melwitt | stephenfin: ok, I _think_ what that's doing is if you pass a class that doesn't exist, it will show you the default (which is not super helpful, but is accurately showing what would be used if you tried to use a nonexistent quota class) | |
| 16:37:57 | stephenfin | what would a real class be? | |
| 16:37:59 | melwitt | stephenfin: if you create a new class and put different values in it and then show it I think (hopefully) it would show you that new class values | |
| 16:38:43 | melwitt | stephenfin: only default out of the box but you can create quota classes, that's the only way you can get other quota classes | |
| 16:39:38 | stephenfin | Ah, apparently *only* 'default' is supported https://docs.openstack.org/nova/latest/admin/quotas.html | |
| 16:39:51 | stephenfin | Only the default class is supported by nova. | |
| 16:39:51 | stephenfin | Note | |
| 16:41:05 | melwitt | yeah, at some point in the past we decided that bc quota classes was a rax specific thing they were doing with an external service/system that they had | |
| 16:41:19 | melwitt | and as far as we knew no one else ever used it | |
| 16:41:32 | stephenfin | Nope, tell a lie. Apparently I wrote the quota docs | |
| 16:41:37 | stephenfin | Jaysus | |
| 16:41:39 | melwitt | :) | |
| 16:42:08 | stephenfin | Okay, so that argument means diddly squat in practice | |
| 16:42:29 | melwitt | so, you're right we don't support it but if you were curious how the command could work, that's how I remember it working | |
| 16:43:12 | stephenfin | Right. I must check if any of this is relevant for neutron or cinder. If not, I might get the interns to deprecate all the class-based stuff in OSC. It's just confusing | |
| 16:43:40 | stephenfin | melwitt++ thanks :) | |
| 16:44:09 | melwitt | stephenfin: yeah, I think it's pretty safe to do that. technically someone could change the default quota class values and nova would use that if it's in the right order of precedence ... but I don't think that really helps anyone | |
| 16:44:36 | melwitt | just increases confusion | |
| 16:45:24 | stephenfin | i.e. using 'quota-class-update'? | |
| 16:45:36 | melwitt | yes | |
| 16:46:28 | stephenfin | Okay. I suspect re-implementing that as e.g. 'openstack quota set --default --instances $INSTANCES' or 'openstack default quota set --instances $INSTANCES' would make more sense | |
| 16:46:46 | stephenfin | and deprecate (for removal) all references to quota classes | |
| 16:47:11 | stephenfin | Sound reasonable? | |
| 16:47:49 | melwitt | yeah, I think that makes sense. quota classes is how you can change defaults over the API (as opposed to the config options). so maybe people do do that (?) | |
| 16:49:10 | stephenfin | yeah, I've no idea, but at least this would be a little more discoverable/require less historical knowledge | |
| 16:49:26 | stephenfin | one more thing: you can set your own quota on a per project basis. What do we call those quotas? Custom quotas? Overridden quotas? Project-specific quotas? | |
| 16:49:52 | melwitt | sean-k-mooney: I don't think it's the reverse ... i.e if you qemu-img info <volume path> it returns raw if you qemu-img info <snapshot path> it returns qcow2. unless I'm just totally misunderstanding something | |
| 16:50:35 | melwitt | stephenfin: the last one, project quotas | |
| 16:50:43 | stephenfin | ta | |
| 16:52:01 | melwitt | sean-k-mooney: <source file='/opt/stack/data/nova/mnt/896fb15da6036b68a917322e72ebfe57/volume-89113873-5c74-4980-8396-f876b7b5101c'/> vs <source file='/opt/stack/data/nova/mnt/896fb15da6036b68a917322e72ebfe57/volume-89113873-5c74-4980-8396-f876b7b5101c.484f7406-3169-4ea5-afda-a7b4657c4d4f' index='1'/> | |
| 16:53:33 | melwitt | the latter is what the instance points to after the snapshot and that path/file format is qcow2 | |
| 17:38:58 | sean-k-mooney | melwitt: so when we create a shapshot we are then running form the delta disk | |
| 17:39:52 | melwitt | sean-k-mooney: right | |
| 17:42:21 | sean-k-mooney | yes so the volume is not the new file in qcow format | |
| 17:42:28 | sean-k-mooney | and the snapshot is the old file | |
| 17:42:40 | sean-k-mooney | because if i boot a second vm form the snapshot | |
| 17:42:52 | sean-k-mooney | i should really get the old files content | |
| 17:43:07 | sean-k-mooney | and creatign the new voluem shoudl create a second deleta disk | |