Tuesday, 2025-11-18

opendevreviewmelanie witt proposed openstack/nova master: TPM: add RequestContext checks to functional tests  https://review.opendev.org/c/openstack/nova/+/96649901:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: support instances with `user` secret security  https://review.opendev.org/c/openstack/nova/+/94250201:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: support instances with `host` secret security  https://review.opendev.org/c/openstack/nova/+/94179501:32
opendevreviewmelanie witt proposed openstack/nova master: Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData  https://review.opendev.org/c/openstack/nova/+/95262801:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: bump service version and require it for live migration  https://review.opendev.org/c/openstack/nova/+/96205101:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: support live migration of `host` secret security  https://review.opendev.org/c/openstack/nova/+/94148301:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: support instances with `deployment` secret security  https://review.opendev.org/c/openstack/nova/+/94202101:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security  https://review.opendev.org/c/openstack/nova/+/92577101:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security  https://review.opendev.org/c/openstack/nova/+/95262901:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security  https://review.opendev.org/c/openstack/nova/+/95697501:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: opt-in to new TPM secret security via resize  https://review.opendev.org/c/openstack/nova/+/96205201:32
opendevreviewmelanie witt proposed openstack/nova master: TPM: add documentation and reno for live migration  https://review.opendev.org/c/openstack/nova/+/96288901:32
opendevreviewmelanie witt proposed openstack/nova master: DNM vtpm tempest  https://review.opendev.org/c/openstack/nova/+/95747701:32
*** mhen_ is now known as mhen02:37
melwittbauzas: thanks for the reviews :) I have updated the bottom two patches you commented on02:46
opendevreviewGhanshyam proposed openstack/nova-specs master: Add spec for Graceful shutodwn of nova services  https://review.opendev.org/c/openstack/nova-specs/+/96746902:54
opendevreviewGhanshyam proposed openstack/nova master: PoC: Graceful shutodwn of nova services  https://review.opendev.org/c/openstack/nova/+/96726103:27
opendevreviewGhanshyam proposed openstack/nova-specs master: Add spec for Graceful shutodwn of nova services  https://review.opendev.org/c/openstack/nova-specs/+/96746903:44
aravindh8murugesan:sean-k-mooney I'm passing an nVidia GPU to few of my VMs in passthrough mode. I have noticed for VM with GPU passthrough, openstack nova is not honoring the memory over commitment ratio? Is this expected. Do I need 1:1 memory for passthrough GPU devices?04:23
aravindh8murugesanMaybe I should word it little clearly, nova does honor the overcommitment and scheduled the VM. So for example if my host has 128GB ram and provisioned VMs come out to about 140gb of RAM allocation, trying to boot up all the VMs at once, forces many of these vm to error state. 04:25
LarsErikPtobias-urdin: thanks. So, I think I read out of the short discussion that followed, that someone is now thinking about merging it? :P07:43
nicolairuckelsean-k-mooney, I talked to some colleagues who also do operations. They said that it would probably be better if a patch for cold migration would be merged in the same cycle as the other operations that are currently in the NVRAM patch and they were afraid that this won't be possible if those are separate patches. They didn't see any issue with shelving in a separate patch. What do you think?08:08
gibisean-k-mooney: re vmware ci. No I don't see it triggering on oslo.vmware patches https://review.opendev.org/c/openstack/oslo.vmware/+/96741808:22
gibibut I can put up nova DNM with depends on to see if that helps08:22
opendevreviewBalazs Gibizer proposed openstack/nova master: DNM:Test with oslo.vmware eventlet removal patches  https://review.opendev.org/c/openstack/nova/+/96748708:27
gibilets see ^^08:27
*** elodilles_pto is now known as elodilles08:51
opendevreviewRajesh Tailor proposed openstack/nova master: Fix memory_details units in diagnostics API to match documentation  https://review.opendev.org/c/openstack/nova/+/96750511:16
opendevreviewsean mooney proposed openstack/nova-specs master: Repropose and update cyborg vGPU (mdev) support  https://review.opendev.org/c/openstack/nova-specs/+/96751511:49
nelljerramHi 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.12:55
gibinelljerram: have you managed to test this patch with calico succesfully?13:02
gibinelljerram: 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 it13:03
nelljerramgibi: Many thanks; I have tested that it works for Calico.13:05
gibicool. approved13:06
gibinelljerram: thanks for fixing it13:07
nelljerramgibi: 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
nelljerramgibi: when tested against Caracal or later, I mean13:07
gibinelljerram: OK. If you can eventually open up that test env then we would appreciate a 3rd party CI with Calico :)13:08
gibinelljerram: feel free to ping me with the backports when you propose them13:08
nelljerramgibi: 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:10
nelljerramgibi: Do I wait until the change is merged to master, before proposing the backports?13:11
gibiI 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
gibinelljerram: no worries I'm not holding breath. :) But I'm happy to see that there is motivated folks trying to open it up13:13
sean-k-mooneygibi: nelljerram the funny thing is we are likely going to end up using managed=no13:24
sean-k-mooneyfor ovs as well in the future or at least with ovn13:24
sean-k-mooneybut before we do that we need to change os-vif to support creating the tap13:24
sean-k-mooneyalso we chagne form interface=bridge to interface=ethernet precincely because it did not delete the tap13:25
sean-k-mooneyso thet libvirt behavior change regressed that again13:25
sean-k-mooneywell not quite we didi dit for the ovs prot defintion13:25
sean-k-mooneyso im remmeber that wrong but its a similr effect13:25
sean-k-mooneyit cause our pre-plugging of the neutron port in pre-livemigrate to be less effective13:26
sean-k-mooneygibi: oh i ment patches to nova13:27
sean-k-mooneygibi: for the vmware changes13:27
sean-k-mooneygibi: do you also need to update oslo.vmware for the eventlet removal13:27
sean-k-mooneylibs in general are not ment ot use eventlet directly but i guess they were for some api requests?13:28
nelljerramsean-k-mooney: interesting, thanks.  I guess that will also be strong motivation for hooking up some Calico CI.13:32
sean-k-mooneywe likely wont be modifying the vif_type=tap code paths but we will be setting the xml atibute form more places13:33
sean-k-mooneywe 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 device13:34
nelljerramsean-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
sean-k-mooneyim not actully sure how to do that exactly but apprently its a thing we can do13:34
sean-k-mooneynelljerram: ah cool good to know13:35
sean-k-mooneyfor what its worht we have several jobs that do live migrationin the ci today on nova13:35
sean-k-mooneywe can lilkely just add calico to one of them13:35
sean-k-mooneysimilar to how the nova-alt-config job use ml2/ovs with iptables instead of ovn13:35
gibisean-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 lib13:36
sean-k-mooneywe just need to choose one of the jobs, enable the devstack plugin and that will give us some coverage13:36
sean-k-mooneygibi: ack, want might be a strong word for it but if its tested then sure13:37
sean-k-mooneygibi: we dont have visablity into the job defition but i assume depend on does nto work for there third party ci13:37
sean-k-mooneyi.e. you cant triger it form nova?13:37
nelljerramthanks, 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:38
sean-k-mooneynelljerram: so we actuly kind of have one13:39
sean-k-mooneynelljerram: there is a neutron test for live migration connectiviy 13:39
sean-k-mooneyhowever because our ci provider are quite slow/overloaded13:40
sean-k-mooneywe have to set the downtime high in the jobs for stablity13:40
gibisean-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
gibipriorities. If Johannes does not take it the I would like to ask if RH can pick it up for G.13:40
gibiahh sorry 13:40
gibiwrong copy paste buffer13:40
sean-k-mooneynelljerram: https://github.com/openstack/tempest/blob/8ccefd4bea48d6b38f7e16c50f97931b3fc2a5e2/tempest/scenario/manager.py#L106213:40
sean-k-mooneythere are live migration test that use that funciton to verify the conenctivy durign the migration13:41
nelljerramsean-k-mooney: thanks!13:41
gibisean-k-mooney: so I tried to trigger it from here but no luck yet https://review.opendev.org/c/openstack/nova/+/96748713:41
gibiI will discuss with fwiesel 13:41
gibiwhen he is arond13:41
sean-k-mooneyack13:42
sean-k-mooneygibi: ya no rush either way i just said i woudl sugget that incase you had not tried it yet13:42
gibiack13:42
sean-k-mooneyif 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 patch13:43
sean-k-mooneymost 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 us13:44
gibiyeah it is likely wont work13:45
*** mikal4 is now known as mikal14:49
opendevreviewMerged openstack/nova master: Add managed='no' flag to libvirt XML definition for VIF type TAP  https://review.opendev.org/c/openstack/nova/+/96028414:57
opendevreviewNell 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/+/96756715:08
opendevreviewNell 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/+/96756815:09
opendevreviewNell 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/+/96756915:09
nelljerramgibi: sean-k-mooney: fyi I've failed the cherry-picks for https://review.opendev.org/c/openstack/nova/+/960284 now; hope I did it right15:14
sean-k-mooneynelljerram: almost15:15
sean-k-mooneyso you are cherrypicking the older patches dreictly form master15:15
sean-k-mooneyyou shoudl cherry pick them form the newer stable branch instead15:15
nelljerram(just spotted that I wrote "failed" when I meant "filed"...)15:16
sean-k-mooneyso 2025.1 should be cherry picked form 2025.2  and it shoudl have 1 "cherry picked from commit" lien per branch15:16
nelljerramso it should be master -> 2025.2, then 2025.2 -> 2025.1, then 2025.1 -> 2024.2 and so on?15:16
sean-k-mooneyyep15:17
gibinelljerram: 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:17
sean-k-mooneythat helps too ya15:18
sean-k-mooneythe master patch shoudl have had "bug/2033681" as the topic15:18
sean-k-mooneybut its too late to change it from https://review.opendev.org/q/topic:%22libvirt-tap-managed-no%2215:18
sean-k-mooneyso "libvirt-tap-managed-no" is fine for all the bafckports15:19
nelljerramright, will change them all to "libvirt-tap-managed-no"15:19
opendevreviewNell 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/+/96756815:27
opendevreviewNell 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/+/96756915:28
nelljerramgibi: sean-k-mooney: hopefully all correct now?15:30
sean-k-mooneythe commit message are not quiter right15:32
sean-k-mooneythey still only have one cherry picked form line15:32
nelljerramOK, 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
sean-k-mooneyyou need to use -x or -X to add the line each time rather hten just a cherry pick without flags15:35
sean-k-mooneynormally i use git-review to do this15:35
nelljerramI 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:36
sean-k-mooneythe web ui wont actully add the cherry-picked form lines properly unless you do it form a merged commit15:37
nelljerramok, let me try this again using git-review...15:37
sean-k-mooneyyou can just edit the commit message in the ui15:38
sean-k-mooneyto add the correct lines15:38
nelljerramOK, I'll try that first, presumably just need to discover the commit IDs...15:38
sean-k-mooneyso 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 ones15:39
sean-k-mooneythe commit is aviabel in the ui beside where you slect the patch set just under where it say Comments15:39
opendevreviewNell 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/+/96756815:41
opendevreviewNell 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/+/96756915:44
nelljerramAh I see.  The commit ID is also available from the gitea link, but the one you pointed to is better.15:49
sean-k-mooneyif you use the cli (with or without git review) you can pass a flag to add it automaticly15:53
sean-k-mooneybut ya you can do it form the ui too15:53
sean-k-mooneywhen i do it form the ui i wait for the previous version to merge ot avoid having to update it15:53
sean-k-mooneyi approved the first backport ill look at the ohter once its merged15:53
nelljerrammany thanks!15:53
opendevreviewMerged openstack/osc-placement master: Replace remaining py39 target  https://review.opendev.org/c/openstack/osc-placement/+/96380916:13
opendevreviewGhanshyam proposed openstack/nova-specs master: Add spec for Graceful shutodwn of nova services  https://review.opendev.org/c/openstack/nova-specs/+/96746916:36
opendevreviewGhanshyam proposed openstack/nova-specs master: Propose Step 1 of Graceful shutodwn spec  https://review.opendev.org/c/openstack/nova-specs/+/96758517:21
Ugglagmaan, question, server_shares policies are PROJECT_MEMBER or PROJECT_READER. Is it normal. Should it be PROJECT_MEMBER_OR_ADMIN or PROJECT_READER_OR_ADMIN respectively ?17:23
jrosserAWS host key signing17:24
jrosserargh17:24
sean-k-mooneyUggla: so project reader allsow anyoen wotih project member to access it17:25
gmaanUggla: *_OR ADMIN should be there as we do want admin to  access those17:25
sean-k-mooneyso really the question is shoudl ti be PROJECT_READER or shoudl it be PROJECT_READER_OR_ADMIN17:25
gmaanyeah admin will not able to access PROJECT_READER  as project id check is there so it should be PROJECT_READER_OR_ADMIN17:26
gmaanPROJECT_MEMBER can access PROJECT_READER as sean-k-mooney mentioned 17:26
sean-k-mooneybasicaly there is role inheritnace the member role grants the reader role and the admin role grant member17:26
sean-k-mooneyso when we write the policy we specify the minium rule that is required17:27
sean-k-mooneythe _OR_ADMIN version 17:27
gmaanyeah17:27
sean-k-mooneyallows admins to bypass the project membership check17:27
sean-k-mooneyi..e its for the --all-tenants type commands17:27
gmaansean-k-mooney: Uggla to avoid using those without OR_ADMIN, i think we should remove these alias and have a note about it there https://github.com/openstack/nova/blob/master/nova/policies/base.py#L41-L4317:28
gmaanI kept them but forgot to add notes about that we need to support admin to access those project scoped role base permission17:29
Ugglagmaan, so as I suspected, it needs to be corrected on the server_shares, I will open a patch for it. ok ?17:30
gmaanUggla: yeah17:30
Ugglagmaan 👍17:31
dansmithmelwitt: did you see bauzas' comment on the user patch about coverage?17:31
dansmithI didn't go validate the concern (yet) but thought maybe you missed it17:31
melwittdansmith: yes, I added coverage. unless I messed up a rebase or upload. I'll check it17:32
dansmithoh, I missed that there was a PS after that comment.. you didn't mark it done so I thought it was fresh17:32
melwittah crap17:33
dansmithI guess I'm also not sure the delta between those PSes is what he was asking about17:34
melwittdansmith: oh really? I thought he was pointing out that use of the image property for tpm_model was not covered?17:37
dansmithI don't know because I don't really know what he's asking.. he said "check the property" and you didn't add any new checks... and the new path excludes the model property17:38
dansmithlike you already had a test that passed the tpm_model property17:39
dansmithohh, as the image prop and not the flavor I guess17:39
melwittyeah17:39
melwittI didn't know what else it could mean but I'm open to maybe I misunderstood something :)17:40
dansmithI'm sure you're right I just didn't make sense of it initially17:40
opendevreviewMerged openstack/nova master: api: Add response body schemas for snapshots APIs  https://review.opendev.org/c/openstack/nova/+/95234917:54
opendevreviewMerged openstack/nova master: api: Add response body schemas for volume attachments APIs  https://review.opendev.org/c/openstack/nova/+/95235017:54
opendevreviewMerged openstack/nova master: api: Add response body schemas for floating IP APIs  https://review.opendev.org/c/openstack/nova/+/95297218:08
opendevreviewMerged openstack/placement master: Make sure [cors] allowed_origin accepts a list value  https://review.opendev.org/c/openstack/placement/+/96627518:08
dansmithmelwitt: would it be possible to move the deployment mode patch down to just above host before we start into all the live migration related bits?18:39
dansmithor is there some dependency there I'm not seeing?18:39
melwittdansmith: I don't think there is a dependency, so I think it can be moved. I'll try it and let you know if I run into anything that could prevent it18:47
dansmithokay, seems like it would be a nice organization to get all three of the modes landed and then review the migration stuff with all that sorted in our (my) minds18:48
dansmithif it's not hard..18:48
melwittyeah, makes sense18:50
opendevreviewStephen Finucane proposed openstack/placement master: setup: Remove pbr's wsgi_scripts  https://review.opendev.org/c/openstack/placement/+/91958219:00
opendevreviewStephen Finucane proposed openstack/placement master: Correct default oslo.conf file  https://review.opendev.org/c/openstack/placement/+/96760019:00
opendevreviewStephen Finucane proposed openstack/placement master: Migrate setup configuration to pyproject.toml  https://review.opendev.org/c/openstack/placement/+/96760119:00
opendevreviewStephen Finucane proposed openstack/placement master: pre-commit: Bump versions  https://review.opendev.org/c/openstack/placement/+/96760219:00
opendevreviewMerged openstack/nova stable/2025.2: Add managed='no' flag to libvirt XML definition for VIF type TAP  https://review.opendev.org/c/openstack/nova/+/96756719:22
opendevreviewmelanie witt proposed openstack/nova master: TPM: support instances with `deployment` secret security  https://review.opendev.org/c/openstack/nova/+/94202119:27
opendevreviewmelanie witt proposed openstack/nova master: Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData  https://review.opendev.org/c/openstack/nova/+/95262819:27
opendevreviewmelanie witt proposed openstack/nova master: TPM: bump service version and require it for live migration  https://review.opendev.org/c/openstack/nova/+/96205119:27
opendevreviewmelanie witt proposed openstack/nova master: TPM: support live migration of `host` secret security  https://review.opendev.org/c/openstack/nova/+/94148319:27
opendevreviewmelanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security  https://review.opendev.org/c/openstack/nova/+/92577119:27
opendevreviewmelanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security  https://review.opendev.org/c/openstack/nova/+/95262919:27
opendevreviewmelanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security  https://review.opendev.org/c/openstack/nova/+/95697519:27
opendevreviewmelanie witt proposed openstack/nova master: TPM: opt-in to new TPM secret security via resize  https://review.opendev.org/c/openstack/nova/+/96205219:27
opendevreviewmelanie witt proposed openstack/nova master: TPM: add documentation and reno for live migration  https://review.opendev.org/c/openstack/nova/+/96288919:27
opendevreviewmelanie witt proposed openstack/nova master: DNM vtpm tempest  https://review.opendev.org/c/openstack/nova/+/95747719:28
dansmithmelwitt: was it that easy?19:31
melwittdansmith: yes, seems so19:33
opendevreviewLajos Katona proposed openstack/nova master: Use SDK for Neutron floating IPs  https://review.opendev.org/c/openstack/nova/+/96260419:33
dansmithdamn I suck at negotiation.. I should have asked for more :P19:34
melwitthah19:34
opendevreviewMerged openstack/placement master: Replace remaining py39 target  https://review.opendev.org/c/openstack/placement/+/96380819:44
opendevreviewMerged openstack/placement master: Remove tags from README  https://review.opendev.org/c/openstack/placement/+/94179219:44
opendevreviewMerged openstack/placement master: Remove installation guide for openSUSE/SLES  https://review.opendev.org/c/openstack/placement/+/94986419:44
opendevreviewGhanshyam proposed openstack/nova-specs master: Add backlog spec for Graceful shutodwn of nova services  https://review.opendev.org/c/openstack/nova-specs/+/96746921:04
opendevreviewGhanshyam proposed openstack/nova-specs master: Propose Step 1 of Graceful shutodwn spec  https://review.opendev.org/c/openstack/nova-specs/+/96758521:11
opendevreviewGhanshyam proposed openstack/nova master: PoC: Graceful shutodwn of nova services  https://review.opendev.org/c/openstack/nova/+/96726121:23
gmaandansmith: gibi: graceful shutdown spec is ready for review (a backlog spec to propose complete things and another change to implement the Step1 proposal for this cycle).21:26
gmaan I uploaded my PoC results, PoC and results links are in spec also. https://review.opendev.org/q/topic:%22bp/nova-services-graceful-shutdown%2221:26
gmaanwhenever you get time, no hurry21:26
opendevreviewGhanshyam proposed openstack/nova master: PoC: Graceful shutodwn of nova services  https://review.opendev.org/c/openstack/nova/+/96726121:54
opendevreviewGhanshyam proposed openstack/nova master: PoC: Graceful shutodwn of nova services  https://review.opendev.org/c/openstack/nova/+/96726123:59

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!