| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-22 | |||
| 13:50:18 | opendevreview | Kaloyan Kotlarski proposed openstack/nova master: Consider using X-Forwarded-Proto only if initial validation fails https://review.opendev.org/c/openstack/nova/+/942510 | |
| 16:24:57 | opendevreview | ribaudr proposed openstack/nova master: Update driver to map the targeted address for SR-IOV PCI devices https://review.opendev.org/c/openstack/nova/+/942147 | |
| 16:24:57 | opendevreview | ribaudr proposed openstack/nova master: Update conductor and filters allowing migration with SR-IOV devices https://review.opendev.org/c/openstack/nova/+/942146 | |
| #openstack-nova - 2025-02-23 | |||
| 13:59:22 | opendevreview | Merged openstack/os-vif master: Deprecate linux bridge plugin https://review.opendev.org/c/openstack/os-vif/+/941585 | |
| 22:01:12 | opendevreview | Steve Baker proposed openstack/nova master: Add VNC console support for the Ironic driver https://review.opendev.org/c/openstack/nova/+/942528 | |
| #openstack-nova - 2025-02-24 | |||
| 07:48:37 | mikal | sean-k-mooney: I am unsure if I should recheck the final spice-direct patch now that melwitt's tempest fix has landed or not. Discuss. | |
| 09:50:32 | opendevreview | Sasha Malberg proposed openstack/nova master: Update SHELVED VM az when attaching disk https://review.opendev.org/c/openstack/nova/+/942561 | |
| 11:38:43 | opendevreview | Vasyl Saienko proposed openstack/nova master: Fix serial console for ironic https://review.opendev.org/c/openstack/nova/+/942575 | |
| 12:02:50 | opendevreview | Amit Uniyal proposed openstack/nova master: Reproducer for cold migration on shared storage https://review.opendev.org/c/openstack/nova/+/940304 | |
| 12:23:24 | opendevreview | Vasyl Saienko proposed openstack/nova master: Fix serial console for ironic https://review.opendev.org/c/openstack/nova/+/942575 | |
| 15:35:13 | opendevreview | Takashi Kajinami proposed openstack/nova master: Use consistent program name for wsgi scripts and entry points https://review.opendev.org/c/openstack/nova/+/942605 | |
| 15:41:57 | opendevreview | Takashi Kajinami proposed openstack/nova master: Use consistent program name for wsgi scripts and entry points https://review.opendev.org/c/openstack/nova/+/942605 | |
| 15:46:43 | sean-k-mooney | Uggla: can you appove this https://review.opendev.org/c/openstack/releases/+/941862 to do the final release of os-vif | |
| 15:48:08 | Uggla | sean-k-mooney, I'll have a look right after the call and will approve it. | |
| 15:48:17 | sean-k-mooney | ack | |
| 15:48:52 | sean-k-mooney | zull is still runing on it anyway | |
| 16:13:17 | Uggla | sean-k-mooney, +1 for me. | |
| 16:13:26 | sean-k-mooney | cool thanks :) | |
| 16:17:23 | danfai | hi, do you think there is a way to make nova aware of a change of the vif_type when live migrating? I'm currently testing live migrations between linuxbridge and OVS/OVN, which seems doable (for our case) but the bridge name is wrong | |
| 16:46:41 | sean-k-mooney | danfai: we do not allow changing the vif_type for port attached to a nova instnace | |
| 16:46:53 | sean-k-mooney | danfai: so you cannot change it form linxu bridge ot ovs/ovn | |
| 16:47:01 | sean-k-mooney | that is unsupproted | |
| 16:47:11 | sean-k-mooney | there are som hacky script to do that on the neutron side | |
| 16:47:19 | sean-k-mooney | but its offically unsuprpoted form a nova perspective | |
| 16:59:51 | pas-ha[m] | Hi all, I'm interested in the status of the 'local disk encryption' work. https://review.opendev.org/q/topic:%22specs/yoga/approved/ephemeral-encryption-libvirt%22 . AFAIU it was kind of abandoned after that CVE flurry last summer... Are there any plans to continue woking on it? can I help with it somehow (rebasing, fixing comments etc)? cc melwitt | |
| 17:03:18 | sean-k-mooney | we coudl add support for it but we might need to chnage the multiple port bidning api respoce to incude vif_type | |
| 17:23:27 | sean-k-mooney | pas-ha[m]: where we are with that is before adding that functionality there is a set of technial debt that we would like to clean up | |
| 17:24:09 | sean-k-mooney | basically our concern is the CVE showed there is a lot of tech debt in the iamge backend code and we are concerned about making it even more complext by adding local disk encyption | |
| 17:25:10 | pas-ha[m] | yeah, I bet at least one of those patches there is my own.. (the ISO one) | |
| 17:25:13 | sean-k-mooney | as melwitt noted the priority of the feature was downgraded and the piority fo the refactorign raised but so far we have not commited to when eitehr will be done | |
| 17:25:32 | sean-k-mooney | pas-ha[m]: which iso one | |
| 17:25:43 | sean-k-mooney | there is at least one i was hoping to land this cycle | |
| 17:25:45 | pas-ha[m] | is there any discussion /docs/aims on the planned refactor you could point me to? | |
| 17:26:03 | pas-ha[m] | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/909611 | |
| 17:26:39 | sean-k-mooney | ah yep thats the one im +2 on. so im hoping melwitt or dan will have time to review that before FF or at least before RC1 | |
| 17:29:06 | pas-ha[m] | bottom line - we are really interested in this feature, as the only proper alternative ATM for local ephemeral encryption is LVM and it starts to be a major operational PITA (no migrations/resize etc).. so if there's anything I could help with I'm all ears 🙂 | |
| 17:29:44 | melwitt | pas-ha[m]: to my understanding, the refactor will be basically the first 3 patches here (maybe just the first 2, will depend on review) https://review.opendev.org/c/openstack/nova/+/925635 obviously I need to rebase and clean up them and I'll write up a blueprint about it. if a spec is needed I will also write a spec | |
| 17:30:18 | pas-ha[m] | thanks, will dive in | |
| 17:30:24 | melwitt | sean-k-mooney: ack I will look at the iso patch | |
| 17:30:59 | sean-k-mooney | melwitt: tldr it will make sure we attach isos as a cdrom rather then as a block device | |
| 17:31:15 | sean-k-mooney | its more subtle then that but that the main part | |
| 17:32:09 | melwitt | ok, thanks | |
| 17:32:51 | pas-ha[m] | fwiw, I recently tried to implement a cold migration / resize for LVM image backend... and it even kind of worked but was ugly AF... really not worth actually doing for sure | |
| 17:34:57 | melwitt | ah, interesting | |
| 17:35:19 | sean-k-mooney | pas-ha[m]: it used to wrok a very long time ago | |
| 17:35:36 | sean-k-mooney | it broke at some point but i have no idea when | |
| 17:36:08 | sean-k-mooney | i dont see why we woudl not supprot it for lvm again eventurlly | |
| 17:36:21 | sean-k-mooney | we just need to scp/rsync the data | |
| 17:36:42 | sean-k-mooney | it very similar to raw/qcow local storage migration | |
| 17:36:51 | sean-k-mooney | we have apis to do this | |
| 17:37:04 | sean-k-mooney | via the remotefs dirvers | |
| 17:37:18 | sean-k-mooney | there is a copy image fucntion for this that lvm shoudl be implementing | |
| 17:37:25 | sean-k-mooney | or using | |
| 17:38:33 | sean-k-mooney | the lvm image backend dirver is the highest perfromign stroage option nova currently supports | |
| 17:38:42 | sean-k-mooney | espically for write intensive operations | |
| 17:38:53 | pas-ha[m] | yeah, kind of what I did. the main problem is that I did not thought of a correct way of dd | ssh | dd to skip the intermediate file, so I was dd to local file, scp to remote, on remote make a new lvm and dd local file into that.. | |
| 17:39:18 | sean-k-mooney | you do not need an a intermediate file | |
| 17:39:50 | sean-k-mooney | dd directly to the remote lvm volume shoudl be enough | |
| 17:40:23 | sean-k-mooney | that is an optimistaion howver | |
| 17:41:06 | pas-ha[m] | also, it seems the libvirt itself does support the migration with lvm, even live one, but for that this lvm must be managed by libvirt itself as a storage pool... which is to much of a rewrite for how nova manages local storage I guess.. | |
| 17:41:40 | sean-k-mooney | i think you can live migrate without the storage pool | |
| 17:41:50 | sean-k-mooney | but for cold migration it need it yes | |
| 17:42:01 | sean-k-mooney | and ya we have no plans to use libvirt sotrage pools in the future | |
| 17:44:13 | sean-k-mooney | libivrt is one of those things that is a doubel edge sword. it provides some useful abstration over qemu but at a cost of addtioanl complexity in the tech stack | |
| 17:44:26 | sean-k-mooney | for the most part its been a win | |
| 17:44:29 | sean-k-mooney | but not alwasys | |
| 17:57:36 | melwitt | hi all, I need a second reviewer on this not-yet-released-regression fix (partial revert) related to tpool.Proxy + libvirt listDevices() if anyone could please look https://review.opendev.org/q/topic:%22bug/2098892%22 | |
| 17:58:16 | sean-k-mooney | oh right i have reviewd that already so someone other then melwitt or i | |
| 17:59:42 | sean-k-mooney | bauzas: gibi this impacts gpus and pci passthough so perhaps ye could find time dansmith may also have context since we chatted about it a little when it was found downstream | |
| 18:00:11 | sean-k-mooney | melwitt: thats needed on stable too yes? | |
| 18:00:37 | sean-k-mooney | i dont think we have done a release with it yet | |
| 18:00:51 | sean-k-mooney | but we sould avoid doing one until the latests patches are included | |
| 18:00:56 | melwitt | yes, it is needed on 4 stable branches also :( | |
| 18:04:02 | gibi | sean-k-mooney: I'm out of energy today, made a note to check it tomorrow | |
| 18:22:43 | sshmlbrg | sean-k-mooney: o/ Could u plz review this mr https://review.opendev.org/c/openstack/nova/+/942561 ? | |
| 18:32:19 | dansmith | melwitt: question hre: https://review.opendev.org/c/openstack/nova/+/942334/6/nova/virt/libvirt/host.py | |
| 18:36:47 | dansmith | ah, nevermind, it's in the commit message below the fold | |
| 18:41:26 | melwitt | thanks dansmith! | |
| 18:48:33 | danfai | sean-k-mooney: thanks for the response re vif_type change. sorry only saw the message now. what I wondered was during a migration, the target hypervisor could have a different model. from what I see nova picks up the new vif_type after the migration, but the bridge_name is at that time wrong | |
| 18:50:56 | sean-k-mooney | so it used to be possibale a long time ago to live migrate between linux bridge and ovs | |
| 18:51:06 | sean-k-mooney | danfai: and i had patches up to fix the bridge name | |
| 18:51:15 | sean-k-mooney | but i dont think neuton ever merged them | |
| 18:51:21 | sean-k-mooney | ill see if i still have the fixes in gerrit | |
| 18:52:01 | danfai | thanks, I saw some comments in the code base from you and mriedem :) | |
| 18:52:13 | sean-k-mooney | https://bugs.launchpad.net/neutron/+bug/1788009 | |
| 18:52:39 | sean-k-mooney | we fixed it for ml2/ovs | |
| 18:52:53 | sean-k-mooney | but ml2/ovn didnt populated it proeprly | |
| 18:53:15 | sean-k-mooney | i think that is still a gap in tehr migration tooling but it might have got fixed in the last year or two | |
| 18:53:38 | danfai | oh, ok. I'll have a more detailed look on the neutron side then. We are still in yoga, so... | |
| 18:54:00 | sean-k-mooney | danfai: for what ite work codl migration shoudl still work i think | |
| 18:54:12 | sean-k-mooney | its been a long time since i tried to fix this | |
| 18:54:27 | mikal | Morning | |
| 18:54:34 | sean-k-mooney | danfai: if your using vlan networking with linux breige yoru move will be less painful | |
| 18:54:45 | danfai | cold migration works flawlessly indeed. also two live migrations (we only have provider networks though) | |
| 18:54:48 | sean-k-mooney | danfai: but just be aware ovn does not supprot vxlan or gre tunnes | |
| 18:54:53 | mikal | sean-k-mooney: I feel like I should recheck the spice-direct final patch now that melwitt's tempest fix has landed. Do you see any reason to not do that? | |
| 18:55:10 | sean-k-mooney | mikal:i already did | |
| 18:55:14 | sean-k-mooney | did it fail again | |
| 18:55:21 | sean-k-mooney | mikal: i have started merging your code | |
| 18:55:39 | mikal | sean-k-mooney: doh, I mismashed the refresh button because I am pre coffee. | |