| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 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 | |
| 16:31:31 | dansmith | kashyap: okay not sure how, but happy to look | |
| 16:31:49 | sean-k-mooney | it might be doable but we reuse span in hard reboot | |
| 16:31:58 | dansmith | sean-k-mooney: just spawn, AFAIK, which seems fine as we record other such things IIRC, but whatever | |
| 16:32:03 | kashyap | dansmith: https://opendev.org/openstack/nova/commit/de512f2c025 | |
| 16:32:04 | sean-k-mooney | so we will need to tell the different betweeen first boot and subsequint | |
| 16:32:08 | dansmith | just trying to avoid needing a cycle to change *and* annotate all existing instances | |
| 16:32:15 | kashyap | (It's slow to load) | |
| 16:32:41 | sean-k-mooney | dansmith: i guess we could try and implement that and see what it looks like | |
| 16:32:54 | dansmith | we can talk outside the meeting about it | |
| 16:32:57 | kashyap | Yeah | |
| 16:33:06 | kashyap | Thanks for the design discussion so far! | |
| 16:33:17 | kashyap | gibi: Any other topics? We can hash it outside of the meeting | |
| 16:33:17 | gibi | OK. then I hold on approving the bp until you agree on the way forward | |
| 16:33:38 | gibi | sean-k-mooney has one more headsup I think | |
| 16:33:44 | gibi | so moving on to that | |