Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-11-18
11:16:06 opendevreview Rajesh Tailor proposed openstack/nova master: Fix memory_details units in diagnostics API to match documentation https://review.opendev.org/c/openstack/nova/+/967505
11:49:48 opendevreview sean mooney proposed openstack/nova-specs master: Repropose and update cyborg vGPU (mdev) support https://review.opendev.org/c/openstack/nova-specs/+/967515
12:55:15 nelljerram Hi all. Could someone take a look at https://review.opendev.org/c/openstack/nova/+/960284? It already has one +2 from Sean but would appreciate a second core review.
13:02:58 gibi nelljerram: have you managed to test this patch with calico succesfully?
13:03:57 gibi nelljerram: the patch looks good to me and it is low risk for us upstream as it only touches a very specific code path. So if it works for calico then I'm fine approving it
13:05:38 nelljerram gibi: Many thanks; I have tested that it works for Calico.
13:06:58 gibi cool. approved
13:07:03 gibi nelljerram: thanks for fixing it
13:07:19 nelljerram gibi: To add a bit more detail, we have a pretty extensive system test - unfortunately closed source at the moment - and it completely fails without this patch, but passes with it.
13:07:49 nelljerram gibi: when tested against Caracal or later, I mean
13:08:12 gibi nelljerram: OK. If you can eventually open up that test env then we would appreciate a 3rd party CI with Calico :)
13:08:25 gibi nelljerram: feel free to ping me with the backports when you propose them
13:10:27 nelljerram gibi: Thanks so much. I would indeed like to open up the testing, and will work towards also connecting that to OpenStack CI. But I expect that will take a little while, so please don't hold your breath for it!
13:11:28 nelljerram gibi: Do I wait until the change is merged to master, before proposing the backports?
13:13:17 gibi I think you can start backporting with `git cherry-pick -x ` It is unlikely that the hash of the commit will change now. But if it does then you just respin the backport to point to the final hash.
13:13:59 gibi nelljerram: no worries I'm not holding breath. :) But I'm happy to see that there is motivated folks trying to open it up
13:24:09 sean-k-mooney gibi: nelljerram the funny thing is we are likely going to end up using managed=no
13:24:19 sean-k-mooney for ovs as well in the future or at least with ovn
13:24:39 sean-k-mooney but before we do that we need to change os-vif to support creating the tap
13:25:25 sean-k-mooney also we chagne form interface=bridge to interface=ethernet precincely because it did not delete the tap
13:25:32 sean-k-mooney so thet libvirt behavior change regressed that again
13:25:42 sean-k-mooney well not quite we didi dit for the ovs prot defintion
13:25:58 sean-k-mooney so im remmeber that wrong but its a similr effect
13:26:32 sean-k-mooney it cause our pre-plugging of the neutron port in pre-livemigrate to be less effective
13:27:22 sean-k-mooney gibi: oh i ment patches to nova
13:27:29 sean-k-mooney gibi: for the vmware changes
13:27:47 sean-k-mooney gibi: do you also need to update oslo.vmware for the eventlet removal
13:28:19 sean-k-mooney libs in general are not ment ot use eventlet directly but i guess they were for some api requests?
13:32:44 nelljerram sean-k-mooney: interesting, thanks. I guess that will also be strong motivation for hooking up some Calico CI.
13:33:56 sean-k-mooney we likely wont be modifying the vif_type=tap code paths but we will be setting the xml atibute form more places
13:34:24 sean-k-mooney we basiclly need neutron to tell us to do it in the vif_details and as i said extened os-vif to be able to create the tap device
13:34:37 nelljerram sean-k-mooney: fwiw I am also currently working on pre-livemigrate for Calico. Currently we ignore that and just flip the port over when migration completes - which is not very seamless :-)
13:34:40 sean-k-mooney im not actully sure how to do that exactly but apprently its a thing we can do
13:35:02 sean-k-mooney nelljerram: ah cool good to know
13:35:28 sean-k-mooney for what its worht we have several jobs that do live migrationin the ci today on nova
13:35:35 sean-k-mooney we can lilkely just add calico to one of them
13:35:56 sean-k-mooney similar to how the nova-alt-config job use ml2/ovs with iptables instead of ovn
13:36:10 gibi sean-k-mooney: oslo_vmware had some home made looping calls, a bit of greenthread.sleep and an eventlet.timeout for image download. So yeah if we want to keep support the vmware virt driver in native threading mode we need changes in the lib
13:36:18 sean-k-mooney we just need to choose one of the jobs, enable the devstack plugin and that will give us some coverage
13:37:01 sean-k-mooney gibi: ack, want might be a strong word for it but if its tested then sure
13:37:35 sean-k-mooney gibi: we dont have visablity into the job defition but i assume depend on does nto work for there third party ci
13:37:43 sean-k-mooney i.e. you cant triger it form nova?
13:38:24 nelljerram thanks, I'll take a look at those. I've found it surprisingly hard to write an effective test for fully seamless live migration. I mean I already have a test that tests continuity of an SSH connection to a guest, across a live migration, and it passes, even though our live plumbing migration is really not properly seamless yet.
13:39:43 sean-k-mooney nelljerram: so we actuly kind of have one
13:39:58 sean-k-mooney nelljerram: there is a neutron test for live migration connectiviy
13:40:10 sean-k-mooney however because our ci provider are quite slow/overloaded
13:40:24 sean-k-mooney we have to set the downtime high in the jobs for stablity
13:40:38 gibi sean-k-mooney: I tried here but it did not triggered (yet) There is also a spec about changing the device attach APIs async. Currently owned by Dan but expected to be taken over by Johannes (outside RH) https://review.opendev.org/c/openstack/nova-specs/+/958900 that I personally care about due to eventlet removal relatedness. If Johannes take it then I would like to get this on the list of
13:40:44 gibi priorities. If Johannes does not take it the I would like to ask if RH can pick it up for G.
13:40:47 gibi ahh sorry
13:40:50 gibi wrong copy paste buffer
13:40:57 sean-k-mooney nelljerram: https://github.com/openstack/tempest/blob/8ccefd4bea48d6b38f7e16c50f97931b3fc2a5e2/tempest/scenario/manager.py#L1062
13:41:13 sean-k-mooney there are live migration test that use that funciton to verify the conenctivy durign the migration
13:41:15 nelljerram sean-k-mooney: thanks!
13:41:19 gibi sean-k-mooney: so I tried to trigger it from here but no luck yet https://review.opendev.org/c/openstack/nova/+/967487
13:41:31 gibi I will discuss with fwiesel
13:41:39 gibi when he is arond
13:42:15 sean-k-mooney ack
13:42:41 sean-k-mooney gibi: ya no rush either way i just said i woudl sugget that incase you had not tried it yet
13:42:56 gibi ack
13:43:12 sean-k-mooney if the job is not using zuul or even if it is but is not usign requreed project and devstack it woudl not pull in the patch
13:44:18 sean-k-mooney most job devs dont include libs in required prodject to test with the released verion outside the lib repo so my guess is this wont actully work unless they do some tweaks to test it for us
13:45:33 gibi yeah it is likely wont work
14:57:19 opendevreview Merged openstack/nova master: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/960284
15:08:36 opendevreview Nell Jerram proposed openstack/nova stable/2025.2: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/967567
15:09:30 opendevreview Nell Jerram proposed openstack/nova stable/2025.1: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/967568
15:09:59 opendevreview Nell Jerram proposed openstack/nova stable/2024.2: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/967569
15:14:17 nelljerram gibi: sean-k-mooney: fyi I've failed the cherry-picks for https://review.opendev.org/c/openstack/nova/+/960284 now; hope I did it right
15:15:08 sean-k-mooney nelljerram: almost
15:15:23 sean-k-mooney so you are cherrypicking the older patches dreictly form master
15:15:38 sean-k-mooney you shoudl cherry pick them form the newer stable branch instead
15:16:09 nelljerram (just spotted that I wrote "failed" when I meant "filed"...)
15:16:12 sean-k-mooney so 2025.1 should be cherry picked form 2025.2 and it shoudl have 1 "cherry picked from commit" lien per branch
15:16:57 nelljerram so it should be master -> 2025.2, then 2025.2 -> 2025.1, then 2025.1 -> 2024.2 and so on?
15:17:48 sean-k-mooney yep
15:17:55 gibi nelljerram: also a small nit, please change the topic of the gerrit reviews to have the same topic as the master patch, that help discovering the reviews
15:18:13 sean-k-mooney that helps too ya
15:18:35 sean-k-mooney the master patch shoudl have had "bug/2033681" as the topic
15:18:46 sean-k-mooney but its too late to change it from https://review.opendev.org/q/topic:%22libvirt-tap-managed-no%22
15:19:02 sean-k-mooney so "libvirt-tap-managed-no" is fine for all the bafckports
15:19:52 nelljerram right, will change them all to "libvirt-tap-managed-no"
15:27:26 opendevreview Nell Jerram proposed openstack/nova stable/2025.1: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/967568
15:28:43 opendevreview Nell Jerram proposed openstack/nova stable/2024.2: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/967569
15:30:33 nelljerram gibi: sean-k-mooney: hopefully all correct now?
15:32:01 sean-k-mooney the commit message are not quiter right
15:32:15 sean-k-mooney they still only have one cherry picked form line
15:35:01 nelljerram OK, I guess that's because the message wasn't recreated when I redid the picks in order. Let me try to fix that manually...
15:35:37 sean-k-mooney you need to use -x or -X to add the line each time rather hten just a cherry pick without flags
15:35:45 sean-k-mooney normally i use git-review to do this
15:36:47 nelljerram I did it using the web UI at review.opendev.org - is that not recommended? (the vertical dots menu on the top right, then "Cherry pick")
15:37:18 sean-k-mooney the web ui wont actully add the cherry-picked form lines properly unless you do it form a merged commit
15:37:41 nelljerram ok, let me try this again using git-review...
15:38:04 sean-k-mooney you can just edit the commit message in the ui
15:38:08 sean-k-mooney to add the correct lines
15:38:40 nelljerram OK, I'll try that first, presumably just need to discover the commit IDs...
15:39:04 sean-k-mooney so the reason we do it this way is if there is a merge conflict along the way you fix it only in the correct only in the banch that it happend in hten cherry pick the fixed version to older ones
15:39:32 sean-k-mooney the commit is aviabel in the ui beside where you slect the patch set just under where it say Comments
15:41:33 opendevreview Nell Jerram proposed openstack/nova stable/2025.1: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/967568
15:44:16 opendevreview Nell Jerram proposed openstack/nova stable/2024.2: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/967569
15:49:07 nelljerram Ah I see. The commit ID is also available from the gitea link, but the one you pointed to is better.

Earlier   Later