| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 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 | |
| 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 | 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:13 | stephenfin | so previously, we had | |
| 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 | |
| 16:38:28 | sean-k-mooney | this is the poc but it has a bug (ovs bridge) patch | <---> | patch (ovs bridge) tap | <---> | VM | |
| 16:38:34 | sean-k-mooney | https://review.opendev.org/c/openstack/os-vif/+/798055 | |
| 16:39:00 | sean-k-mooney | currently its configurable and defualting to true for development | |
| 16:39:08 | stephenfin | do we need to worry about flows getting added for the patch <-> tap in the second (new) bridge? | |
| 16:39:13 | stephenfin | or does that happen automatically? | |
| 16:39:24 | sean-k-mooney | stephenfin: just the normal action | |
| 16:39:33 | sean-k-mooney | so no rules required | |
| 16:39:50 | sean-k-mooney | on the neutron side if we wanted to proceed there woudl need to be some qos changes for ovn | |
| 16:39:57 | sean-k-mooney | so that will be covered by a spec | |
| 16:40:24 | sean-k-mooney | if we are ok with this on the nova side i would like to track the capablity as a bug against os-vif | |
| 16:40:48 | sean-k-mooney | so we can backport the ablity to opt in tothis behavor but not use it by default for stable branches | |
| 16:40:59 | stephenfin | excellent, so we'll pre-populate a flow in the br-int for the new patch port, and then the comms from the other side of the patch port to the VM don't need anything explicit bar the normal action | |
| 16:41:07 | stephenfin | that wfm, personally | |
| 16:41:26 | stephenfin | certainly seems better than re-adding hybrid plug with the OVS -> linux bridge -> VM dance | |
| 16:41:47 | sean-k-mooney | i guess may main question is bug blueprint or spec for this | |
| 16:43:01 | stephenfin | I would like to see some high level docs on this _somewhere_ | |
| 16:43:02 | gibi | hm, if this requires a neutron spec, then why do you need to backport the os-vif change to stable? | |
| 16:43:12 | sean-k-mooney | personally i would prefer to leave this bake for a cycle and enable it by default next cycle | |
| 16:43:23 | sean-k-mooney | gibi: the neutorn spec is to fix QOS support | |
| 16:43:29 | stephenfin | it could be a blueprint but docs in the neutron tree might be better | |
| 16:43:37 | gibi | sean-k-mooney: ahh OK I see | |
| 16:43:40 | sean-k-mooney | it would be useful for those that dont need qos without that | |
| 16:43:48 | gibi | yepp now I got it | |
| 16:44:07 | gibi | this is a bugfix for os-vif to support live migration with OVN | |
| 16:44:23 | gibi | or more preciesly fix a race in live migration | |
| 16:44:28 | gibi | I can live with this as a bugfix | |
| 16:44:37 | sean-k-mooney | yes basically | |
| 16:45:13 | sean-k-mooney | and thats also why we woudl default this to off intially and then enable it by default in the future | |
| 16:45:30 | gibi | any objection? | |