| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-22 | |||
| 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 | gibi | gmann, stephenfin: sorry I focused elsewhere. I see stephenfin approved it now | |
| 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: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 | Note | |
| 16:39:51 | stephenfin | Only the default class is supported by nova. | |
| 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 | |
| 17:43:12 | melwitt | oh, ok I think I see what you're saying | |
| 17:43:55 | sean-k-mooney | its kind of the reverse of what you woudl expect | |
| 17:44:18 | melwitt | yeah. I have clearly been confused by all of this 😆 | |
| 17:44:29 | sean-k-mooney | normally we upload a new image to glance with the delta form the base file | |
| 17:44:49 | sean-k-mooney | but the base file does not change with glance | |
| 17:44:58 | sean-k-mooney | but with a voluem it writable | |
| 17:45:11 | sean-k-mooney | so the volume becomes the new file | |
| 17:45:18 | sean-k-mooney | and the snapshot is the old file | |
| 17:46:38 | sean-k-mooney | that i think is how we should look at it but maybe that is not how cinder looks at it | |
| 17:47:11 | sean-k-mooney | to me the voluem is the thing attached to the vm and the snapshot is the backing file | |
| 17:48:45 | melwitt | yeah, it is presented that way as in, the instance remains attached to the same volume uuid, even after snapshots | |
| 17:49:00 | melwitt | (when you look at server show, for example) | |
| 17:49:36 | melwitt | that's part of why it confuses me bc it's attached to the volume but then the xml points at the delta | |
| 17:54:01 | sean-k-mooney | yep so that is why we probly need to change the forma on the volume | |
| 17:54:19 | sean-k-mooney | and keep the format of the snapshot at the current romat of the disk | |
| 17:54:41 | sean-k-mooney | a second snapshot will result in the qcow the vm is now using being the snapshot disk | |
| 17:54:52 | sean-k-mooney | so the second snabp shot format will be qcow | |
| 17:54:58 | sean-k-mooney | but that ok | |
| 17:55:10 | sean-k-mooney | the rule is | |
| 17:55:19 | sean-k-mooney | the format of the snapshot is the current volume format | |
| 17:55:33 | sean-k-mooney | and the volmue format after snapstho is always qcow | |
| 17:57:19 | melwitt | sean-k-mooney: ok. so PS1 of my cinder patch was likely the right approach. and the volume extend failure is expected and should be skipped if nfs is being used, until that spec you linked earlier is implemented (?) | |
| 18:00:12 | sean-k-mooney | i belive so | |
| 18:00:33 | sean-k-mooney | the patch you linked me would also proably work as a workaround | |
| 18:00:51 | sean-k-mooney | but i dont belive it would be the right long term solution | |
| 18:00:59 | melwitt | gotcha | |
| 18:11:40 | sean-k-mooney | o/ | |