Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-29
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 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:40 kashyap bauzas: No; they can opt out of it here.
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 dansmith kashyap: okay not sure how, but happy to look
16:31:31 sean-k-mooney dansmith: that will complicate the inital spawn logic and posibel hard reboot
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 gibi OK. then I hold on approving the bp until you agree on the way forward
16:33:17 kashyap gibi: Any other topics? We can hash it outside of the meeting
16:33:38 gibi sean-k-mooney has one more headsup I think
16:33:44 gibi so moving on to that
16:33:45 gibi sean-k-mooney:
16:33:56 sean-k-mooney yes so ovn migration...
16:34:19 sean-k-mooney am tl;dr is architeutlaly there is alwasy a race when doing live migartion with ovn
16:34:44 sean-k-mooney effectivly ovn can only start installing rule when the tap is created on the dest
16:35:00 sean-k-mooney and at that point we have called libvirt to do the migration and its incontol
16:35:16 sean-k-mooney to to avoid that and create the port in prelive migration im proposing an os-vif change
16:35:51 sean-k-mooney baiscly reinotduce hybrid-plug btu with ovs bridges and patch port instead of linux bridges and veth pairs
16:36:07 sean-k-mooney that will not have any perfromance impact on the vm
16:36:19 sean-k-mooney but will allow ovn to isntall the rules in prelive migrate
16:36:35 sean-k-mooney i was wondering how people felt about that
16:37:13 stephenfin so previously, we had
16:37:13 gibi honestly it is too deep networking to me. I assume the impact is mostly in os-vif. Does nova needs to be adapted?
16:37:22 stephenfin (ovs bridge) veth | <---> | veth (linux bridge) tap | <---> | VM
16:37:32 stephenfin and now we'll have
16:37:39 stephenfin (ovs bridge) patch | <---> | patch (ovs bridge) tap | <---> | VM
16:37:56 stephenfin so everything stays in OVS but there's an additional (on top of br-int) bridge?
16:38:07 sean-k-mooney more like (ovs bridge) tap | <---> | VM orginally to (ovs bridge) patch | <---> | patch (ovs bridge) tap | <---> | VM
16:38:18 sean-k-mooney yes

Earlier   Later