| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 16:13:21 | bauzas | yup | |
| 16:13:24 | bauzas | :( :( :( even | |
| 16:13:31 | dansmith | heh, okay | |
| 16:14:11 | gibi | we should have a terapeutic session in the PTG | |
| 16:14:15 | gibi | anyhow moving on | |
| 16:14:17 | gibi | #topic Stable Branches | |
| 16:14:22 | gibi | stable gates should be OK (though 'wait_for_volume_resource_status' intermittently fails) | |
| 16:14:26 | gibi | EOM (from elodilles ) | |
| 16:14:42 | gibi | any other stable news? | |
| 16:15:04 | elodilles | nothing from me for now | |
| 16:15:17 | dansmith | same failure on master a bunch too I think | |
| 16:15:37 | dansmith | the cinder peeps were working on it a couple weeks ago | |
| 16:15:51 | gibi | yeah I think lyarwood is still trying to see what happens in the guest that prevents detaching a volume | |
| 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 | |