| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 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 | |
| 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? | |
| 16:45:39 | sean-k-mooney | operators can opt in early if they want but not change any behavior by default | |
| 16:46:16 | stephenfin | I'm good. Can't speak for others tho | |
| 16:46:27 | gibi | I don't see any hands raised :) | |
| 16:46:33 | sean-k-mooney | we can defer if peopel want to think about it more | |
| 16:46:38 | sean-k-mooney | im still working on the poc | |
| 16:47:09 | sean-k-mooney | my main concern is m2 and spec freeze | |
| 16:47:14 | gibi | it is accepted as a bug now, here. If somebody later has an objection the we can rediscuss but until that this is a bug | |
| 16:47:34 | gibi | Is there any other topic for today | |
| 16:48:31 | sean-k-mooney | not form me | |
| 16:49:00 | gibi | then let's close this | |
| 16:49:04 | gibi | thanks for joining | |
| 16:49:07 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-29-16.00.log.html | |
| 16:49:07 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-29-16.00.txt | |
| 16:49:07 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-29-16.00.html | |
| 16:49:07 | opendevmeet | Meeting ended Tue Jun 29 16:49:07 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:49:07 | gibi | #endmeeting | |
| 16:49:11 | elodilles | o/ | |
| 16:49:21 | gibi | feel free to continue the video mode discussion | |
| 16:49:30 | gibi | I will drop now but will read back tomorrow | |
| 16:49:42 | sean-k-mooney | well quickly the live migration issue https://review.opendev.org/c/openstack/nova/+/742180 should have fixed that | |
| 16:50:03 | sean-k-mooney | this is what previously broke live migration without binding-extended | |
| 16:50:32 | sean-k-mooney | but that is still fully supported so droping binding-extended form ml2/ovn shoudl not result in job failures | |
| 16:50:45 | sean-k-mooney | unless we are talking about cross-cell migration | |
| 16:50:51 | kashyap | Thanks for running it, gibi. | |
| 16:50:54 | sean-k-mooney | *cross-cell resize | |
| 16:51:57 | dansmith | sean-k-mooney: so, looking at the build process, it surely seems like the libvirt driver could just look at vm_state==BUILDING in spawn and annotate the desired default going forward | |
| 16:52:05 | dansmith | doesn't seem overly complicated to me | |
| 16:52:16 | dansmith | unless I'm missing elsewhere that we might be building but not want to do that | |
| 16:52:24 | sean-k-mooney | dansmith: ya i was thinking about that later in the meeting | |
| 16:52:40 | sean-k-mooney | i think your right we can detech inital spwan | |
| 16:53:14 | dansmith | yeah, so IMHO that'd be the way to go | |
| 16:53:54 | sean-k-mooney | dansmith: the quistion that i have is wether we can detect it in a place that is within the virt driver that also has the required info | |
| 16:54:15 | opendevreview | Rodrigo Barbieri proposed openstack/nova stable/train: Error anti-affinity violation on migrations https://review.opendev.org/c/openstack/nova/+/798717 | |