| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-06-17 | |||
| 18:58:35 | melwitt | make sense | |
| 18:58:36 | sean-k-mooney | but the downside is we loose contol over that | |
| 18:58:45 | sean-k-mooney | so our guest abi will alter with theres | |
| 18:59:03 | sean-k-mooney | that is ok i guess since you can use the image property if you care | |
| 18:59:16 | melwitt | and yeah that's the code I was looking and the helper function being called there | |
| 19:00:21 | sean-k-mooney | ya so this https://github.com/openstack/nova/blob/6ed556f4adfd8a98fae2e91204f1ce0484f5dd9d/nova/virt/libvirt/driver.py#L5351-L5367 is basically working around libvit/qemu not doing the right thing by default | |
| 19:01:43 | sean-k-mooney | well and the fact we set a default in the xml generation class | |
| 19:01:51 | sean-k-mooney | so if we remove that default | |
| 19:02:02 | sean-k-mooney | then we might not need all those specal cases | |
| 19:02:37 | melwitt | ok, well one step at a time I guess :P | |
| 19:02:52 | melwitt | I do some local tests to see what happens when I remove the default | |
| 19:02:57 | melwitt | *I'll | |
| 19:03:45 | sean-k-mooney | ok let me know an i can review. https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/ is a review of some to the option and recomendations | |
| 19:04:21 | melwitt | thanks | |
| 19:04:21 | sean-k-mooney | i need to remove the gop device i added by mistake last cycle and add https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#bochs-display | |
| 19:04:45 | sean-k-mooney | apparently gop is only for the bhve hypervior but the libvirt doc did not mention that | |
| 19:06:40 | sean-k-mooney | bochs implements a uefi graphic output protocol (gop) device for kvm | |
| 19:07:03 | sean-k-mooney | so that is the one i should have added | |
| 19:10:06 | sean-k-mooney | melwitt: during the ptg we disucssed breifly the idea of a resize for something other then a flavor change | |
| 19:10:58 | sean-k-mooney | maybe this could be another usecause for that | |
| 19:12:19 | sean-k-mooney | i think this was in the context of changing machine_types where i was suggeign a new retype server action but perhaps something more generic that would update the embed flavor and image with the latest would make more sense | |
| 19:12:40 | sean-k-mooney | e.g. a recreate action but that preserved all ports, volume and disks | |
| 19:14:13 | melwitt | how was that suggestion received, I'm curious heh | |
| 19:14:57 | melwitt | like, I know lots of people would like to do that. in my case, I'm trying to recover from what I consider a bug, the default being set to a deprecated thing and glitching out the vnc console | |
| 19:15:20 | sean-k-mooney | reusing resize was dansmith idea i was thinking it shoudl be its onw server action. not sure if dansmith actully was in favor or just saying if it was to be done i would start there | |
| 19:15:45 | melwitt | ah, cool | |
| 19:16:08 | sean-k-mooney | melwitt: the main think would be that recreate would have to be a move operation like resize so we can validate the new requirement | |
| 19:16:19 | sean-k-mooney | since we cant assume the current host is valid anymore | |
| 19:16:36 | melwitt | yeah. well, we validate the new stuff on a rebuild too since a few releases ago | |
| 19:16:51 | sean-k-mooney | but i think it would fix a lot of the thing that hard reboot fix but which require the flaovr or image properties to be modified | |
| 19:17:06 | sean-k-mooney | melwitt: only if the image changes | |
| 19:17:13 | melwitt | yeah, it would make life a lot easier for a lot of people | |
| 19:17:46 | sean-k-mooney | yeah so i think it has merit but not sure where it sits in the priortiy queue | |
| 19:17:49 | melwitt | yeah, I'm just saying that we validate even during rebuild so I think it makes sense to validate on a recreate/resize if we're consuming new image props etc | |
| 19:18:03 | melwitt | we're already doing it | |
| 19:18:10 | melwitt | *doing similar | |
| 19:18:21 | sean-k-mooney | for me i think it would be a good way to opt into changing the machine type for example | |
| 19:19:59 | sean-k-mooney | anyway im going to go buy icecream and i guess other food before the stores start to close | |
| 19:22:53 | sean-k-mooney | hum not sure if good pr or pr blunder https://www.benjerry.ie/flavours/netflix-and-chillld-ice-cream | |
| 19:28:03 | melwitt | thanks for the video model chat o/ | |
| 19:36:30 | mnaser | is there reasoning behind what has ended up being validated in the api layer and what doesn't get validated in the api layer? | |
| 19:37:03 | mnaser | i haven't replicated this yet (but in theory i can imagine it's possible): end user tried to create a vm where image size > disk size when doing bfv | |
| 19:37:16 | mnaser | and they don't really get much more of a helpful error (and their request gets refused too obviously) | |
| 19:37:35 | mnaser | but only after it fails, in what i assume nova-compute trying to ask cinder to create a disk that's impossible to create | |
| 19:53:43 | melwitt | mnaser: generally we validate whatever we can in the api layer to fail fast and avoid the behavior you're describing (fail later on nova-compute). within reason though, as some checks would involve rpc call to the compute host and we avoid that to some degree | |
| 19:54:24 | melwitt | mnaser: I found this part where we validate the image_min_disk against the volume disk size, but that might be different than just the image size as in your example? https://github.com/openstack/nova/blob/master/nova/compute/api.py#L681 | |
| 19:56:15 | mnaser | melwitt: oh interesting, you're right, i wonder if this is a case where the user did not have min_disk specified.. | |
| 19:56:58 | mnaser | melwitt: oh but we don't do image_size > dest_size | |
| 19:57:15 | mnaser | unlike https://github.com/openstack/nova/blob/master/nova/compute/api.py#L693-L695 | |
| 19:58:01 | mnaser | so i _think_ the scenario is no min_disk but no checks on image_size / dst_size | |
| 19:58:24 | melwitt | right thats what I was saying I wonder if thats different | |
| 19:59:05 | melwitt | actually don't know why it's different but I'm not a bfv expert | |
| 19:59:28 | mnaser | melwitt: i think it is, min_size is taken from a glance property which is user-provided (unless a snapshot is taken) | |
| 19:59:34 | mnaser | so i assume user here uploaded an image without min_size | |
| 20:01:06 | melwitt | yeah I mean I don't know why we wouldn't do the same checks for the volume case | |
| 20:01:15 | melwitt | like is that intentional or an oversight | |
| 20:02:55 | mnaser | melwitt: yeah -- in my opinion its an oversight but indeed, maybe someone knows better :) | |
| 20:02:59 | mnaser | anyhow | |
| 20:03:04 | mnaser | ill have a patch up shortly | |
| 20:05:39 | mnaser | melwitt: i swear i saw you mention a while back a key to click before copying from github which gave you a commit hash'd url instead of master | |
| 20:05:56 | melwitt | it's 'y' | |
| 20:09:09 | mnaser | oh awesome, thanks | |
| 20:09:49 | mnaser | https://bugs.launchpad.net/nova/+bug/1883969 | |
| 20:09:49 | openstack | Launchpad bug 1883969 in OpenStack Compute (nova) "Nova doesn't fail at API layer when image_size > volume_size with BFV" [Undecided,New] | |
| 20:13:08 | melwitt | sweet mnaser++ | |
| 20:14:25 | openstackgerrit | Mohammed Naser proposed openstack/nova master: bfv: check if image_size > volume_size in API https://review.opendev.org/736370 | |
| 20:14:40 | mnaser | melwitt: ^ voila, the unit test i wrote passed locally but i didnt run the whole suite | |
| 20:14:44 | mnaser | it makes sense to me™ | |
| 20:14:44 | mnaser | it makes sense to meâ„¢ | |
| 20:20:08 | openstackgerrit | Mohammed Naser proposed openstack/nova master: bfv: check if image_size > volume_size in API https://review.opendev.org/736370 | |
| 20:36:35 | melwitt | mnaser: cool I'll check it | |
| 22:09:24 | gmann | sean-k-mooney: mnaser and to make listing flavor better (instead of need of --private or --all explicitly ) we should add the admin as default tenant access in private flavor. currently what all admin can list the flavors by default and what all it can delete is not matching. | |
| 22:09:55 | gmann | also --private and --all is all admin things and for non-admin --private is just ignored - https://github.com/openstack/nova/blob/6ed556f4adfd8a98fae2e91204f1ce0484f5dd9d/nova/api/openstack/compute/flavors.py#L106 | |
| 22:13:42 | gmann | if we add admin as default tenant access in private flavor then i think we can solve it in backward compatible way but it will be interop issue so that still need microversion. | |
| #openstack-nova - 2020-06-18 | |||
| 03:37:13 | openstackgerrit | Jinsheng Zhang proposed openstack/nova-specs master: Add nova-support-multiple-boot-volume-with-boot-order-selection spec https://review.opendev.org/736422 | |
| 04:05:12 | openstackgerrit | Jinsheng Zhang proposed openstack/nova-specs master: fix "Line limited" error https://review.opendev.org/736425 | |
| 05:07:20 | openstackgerrit | Jinsheng Zhang proposed openstack/nova-specs master: Add nova-support-multiple-boot-volume-with-boot-order-selection spec https://review.opendev.org/736422 | |
| 05:43:46 | openstackgerrit | Jinsheng Zhang proposed openstack/nova-specs master: Add nova-support-multiple-boot-volume-with-boot-order-selection spec fix document error https://review.opendev.org/736422 | |
| 07:50:29 | gibi | sean-k-mooney, melwitt: re: resize without changing the flavor, the context on the PTG was that changing a resource request of a port might also needs a move operation without changing the flavor | |
| 07:51:28 | gibi | sean-k-mooney, melwitt: I'll try to propose a spec for discussion during this cycle so your input about machine_type change and video mode change being similar use case helps. | |
| 07:52:45 | gibi | sean-k-mooney, melwitt: however I think this spec will be targeted to W not V due to time constraints and discussion needs | |
| 08:00:25 | sean-k-mooney | gibi: ah yes i could not recall what it was in relation too | |
| 08:01:48 | sean-k-mooney | gibi: i think there are other usecases too such as recreatign the vm with the same image and flavor but just updating the embeded copy to pick up change to extra_specs and image metadata without actually imaging the disk | |
| 08:03:24 | gibi | but still cold migrating the VM if the current host is not good for the updted extra_spec / image metadata? | |
| 08:03:35 | sean-k-mooney | gibi: yes | |
| 08:03:48 | sean-k-mooney | i would guess in generall it would be a move opertation | |
| 08:03:49 | gibi | OK, that seems like the same operation that I would need for the qos update | |
| 08:04:13 | sean-k-mooney | it might be vaild to use the same host but likely the schduler would not select the same host | |
| 08:04:30 | sean-k-mooney | it might but basically the same as same host resize | |
| 08:05:11 | sean-k-mooney | i guess we could always add a weigher to make it prefer the same host | |
| 08:05:44 | sean-k-mooney | but thats not really important | |
| 08:08:54 | gibi | yeah, I can imagine that the end user needs an to update these data if it does not cause downtime (cold migration) of the VM | |
| 08:09:13 | gibi | * needs an option to update | |
| 08:09:28 | gibi | but same host resize is still downtime today | |
| 08:09:57 | sean-k-mooney | gibi: currently you need to do a db edit and a hard reboot | |
| 08:10:42 | sean-k-mooney | the downstream issue that melwitt was looking at is related to the fact that in rhel 8.2 the default we use in nova "cirrus" was deprecated | |
| 08:10:44 | sean-k-mooney | https://bugzilla.redhat.com/show_bug.cgi?id=1651994 | |
| 08:10:44 | openstack | sean-k-mooney: Error: Error getting bugzilla.redhat.com bug #1651994: NotPermitted | |
| 08:11:01 | sean-k-mooney | oh thats private well that is what it was tracking | |
| 08:11:43 | sean-k-mooney | anyway 16.0 which is based on train was released on 8.1 16.1 will be on 8.2 | |