Earlier  
Posted Nick Remark
#openstack-nova - 2021-06-29
16:16:18 dansmith well, the cinder peeps were thinking it was an lvm segv or something
16:16:29 dansmith (on the host)
16:16:46 sean-k-mooney have we check that the falvor have at least 2 cores. its really just a workaroudn but i think that help downstream at one point with the guest not respondind to the detach
16:17:34 gibi dansmith: could be multiple indendependent failure I only hit the detach one last week but I'm did not looked at CI results recently
16:17:37 sean-k-mooney i mean 1 shoudl really be enought but sometiems if the guest has 2 cores it will still be abel to repsond if its hung on other thngs
16:18:05 dansmith gibi: yeah, they already fixed one thing that manifested in the same way I think, which was specifically timeout related IIRC
16:18:16 dansmith but the latest was lvm crashing I think
16:18:16 dansmith anyway
16:18:27 gibi dansmith: thansk that is good info
16:18:30 gibi sean-k-mooney: good idea
16:18:36 gibi moving on
16:18:38 gibi #topic Sub/related team Highlights
16:18:43 gibi bauzas: are you still with us?
16:18:55 bauzas yup
16:19:07 bauzas nothing to report, sir.
16:19:09 gibi then
16:19:10 gibi Libvirt (bauzas)
16:19:12 gibi ack
16:19:13 gibi thanks
16:19:13 bauzas this^
16:19:15 gibi :)
16:19:23 gibi moving on
16:19:23 gibi #topic Open discussion
16:19:27 gibi (kashyap) seeking approval for the specless bp https://blueprints.launchpad.net/nova/+spec/virtio-as-default-display-device
16:19:34 kashyap gibi: So on that:
16:19:43 gibi I think this was discussed today on the channel
16:19:47 kashyap I was reminded that we can't do the switch in the current devel cycle
16:20:03 kashyap But we need some preperatory work for Y release
16:20:22 kashyap E.g. recording the video model in system_metadata. Get the tests sorted, and then do the switch.
16:20:42 gibi OK, so then for X you only aim for the recording and testing then switch in Y
16:20:58 dansmith why do we need to record the video model
16:20:59 dansmith ?
16:21:17 sean-k-mooney to prevent it chanigng for exisating vm after upgrade and hard reboot
16:21:18 gibi I think it is to avoid changing ABI to the gues during hard reboot
16:21:28 kashyap dansmith: Upthread, sean-k-mooney was saying it might
16:21:29 sean-k-mooney yes that ^
16:21:32 kashyap But:
16:21:40 dansmith is that because we're changing our default?
16:21:44 dansmith oh
16:21:45 kashyap There won't be any _visible_ breakage here:
16:21:49 kashyap dansmith: Yep
16:21:54 dansmith I thought the spec was adding it as an option, this is for changing the default, I see
16:21:56 kashyap Sorry, I should've given a summary here.
16:22:10 kashyap dansmith: The first sentence of the BP says: "Change Nova's default video display from 'cirrus' to 'virtio'." :-)
16:22:11 sean-k-mooney dansmith: ya we added virtio i think in train
16:22:47 sean-k-mooney so in this specific case it actuly might be safe to jsut make the change
16:23:00 sean-k-mooney because fo vga fallback mode
16:23:07 kashyap Yeah
16:23:08 dansmith well, I was going to say, i think we've made such changes in the past after some interval
16:23:09 sean-k-mooney but in general for device model default changes
16:23:14 sean-k-mooney we woudl have to recored then change
16:23:15 kashyap dansmith: To summarize the above:
16:23:44 kashyap If your guest has the kernel driver, then "virtio" display dev will make use of it; or else, it'll gracefully fallback to VGA
16:23:49 sean-k-mooney dansmith: the only one i can think of was enabling the RNG by default
16:23:55 kashyap So that's the recommended option from the QEMU graphics maints
16:24:10 kashyap sean-k-mooney: Yep
16:24:14 dansmith kashyap: fall back to cirrus?
16:24:33 kashyap dansmith: No, no; fall back to "VGA compatibility mode", which is still better than "cirrus"
16:24:34 sean-k-mooney dansmith: no the virtio-gpu device support a vga hardware interface
16:24:55 dansmith okay
16:24:56 sean-k-mooney dansmith: you just wont get all the fatures but it shold funciton simialr to cirrus in the guest
16:24:58 kashyap I.e. standard VGA.
16:25:02 kashyap Yes
16:25:10 bauzas do operators would opt into it ?
16:25:14 dansmith yeah, but that might freak out a windows machine if your display adapter suddenly changes I guess
16:25:39 bauzas or would we need to change the default automatically ?
16:25:40 kashyap bauzas: No; they can opt out of it here.
16:25:40 sean-k-mooney dansmith: on reboot it should be ok but that was the upgrade concern that would prompt recored then change next cycle
16:25:58 bauzas I understand dansmith's concern about freaking out if done automatically
16:25:59 kashyap bauzas: Yes, we should do the right thing here by changing the defaul.
16:26:06 sean-k-mooney kashyap: not for existing instahce you need to use hw_video_model in the image
16:26:10 kashyap bauzas: dansmith's good point is for Windows
16:26:31 kashyap sean-k-mooney: Right; obvious the default implies only for the new ones.
16:26:35 sean-k-mooney so tl;dr recored in X change in Y ?
16:26:37 kashyap s/obvious/obviously,/
16:26:53 dansmith so the problem is for people who don't have hw_video_model in their image meta right?
16:26:54 kashyap sean-k-mooney: But _do_ we need to record at all? As there's no breakage here
16:27:03 sean-k-mooney dansmith: correct
16:27:08 dansmith can we just create all new instances with that set to the default if they don't have it in their image?
16:27:17 dansmith then we're good for next time too when we switch to whizbang32 video
16:27:28 bauzas can't wait for it
16:27:53 dansmith compute assumes cirrus if unset forever, otherwise honors what it's set to, and then we can make the switch now for any new instances
16:27:57 sean-k-mooney dansmith: not really but we can store our default in the instance_system_metadata
16:28:16 sean-k-mooney which is what we are now doing for machine_type as if it was set in the image
16:28:20 dansmith sean-k-mooney: not really? we mirror image meta in sysmeta already right? so we'd just be using that instead of a bespoke key?
16:28:44 sean-k-mooney dansmith: ya so we can set it in our copy which is what kashyap was going to do
16:28:50 dansmith mirror *some* of image_meta I mean
16:29:09 sean-k-mooney we just cant set it in glance unless we just document use the glance import plugin to set it on all uploaded images
16:29:13 dansmith ack, okay, then we don't need a warning cycle to switch the default if we do it that way
16:29:21 dansmith sean-k-mooney: right I'm talking about our local copy (of course)
16:29:41 sean-k-mooney dansmith: so unless we backport the recording of the current value we would still need one cycle
16:29:53 dansmith why?
16:30:05 sean-k-mooney to populate the instance_metadata_table for exisiting instnaces
16:30:08 kashyap sean-k-mooney: Yeah, why? I still don't see it.
16:30:17 dansmith no, we just assume cirrus forever if unset
16:30:30 sean-k-mooney oh
16:30:43 sean-k-mooney that just means dont change the default
16:30:51 dansmith past the virtio default, it'll always be set to something, so if set, honor that, else cirrus (but just on the compute).. new instances always get virtio set explicitly by default on create
16:30:54 kashyap dansmith: So we can even directly change w/o even recording it in system_metadata, as we did for virtio-rng (I'll get the commit later for you to read)
16:31:31 sean-k-mooney dansmith: that will complicate the inital spawn logic and posibel hard reboot

Earlier   Later