| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 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 | |
| 16:54:17 | sean-k-mooney | i dont belive it will still be in building when we are generating the xml | |
| 16:54:23 | dansmith | well, it's set to building right before we get our spawn called | |
| 16:54:55 | sean-k-mooney | yes but we might need to pass down a flag internally in the driver | |