Friday, 2025-08-15

opendevreviewmelanie witt proposed openstack/nova master: DNM vtpm tempest  https://review.opendev.org/c/openstack/nova/+/95747700:25
*** mhen_ is now known as mhen01:28
opendevreviewMerged openstack/os-vif stable/2024.2: OVS Trunk: Add bridge_name to external_ids  https://review.opendev.org/c/openstack/os-vif/+/95277802:44
opendevreviewMerged openstack/nova master: Run nova-next with n-sch in threading mode  https://review.opendev.org/c/openstack/nova/+/94845004:48
opendevreviewMerged openstack/nova stable/2024.1: Use dict object for request_specs_dict in the _list_view  https://review.opendev.org/c/openstack/nova/+/95530506:11
gibimelwitt: dansmith: replied in the vtpm series https://review.opendev.org/c/openstack/nova/+/941483/21#message-f8bc46bbe27eeb78f1ec79040932d9e3fa2db062 07:22
opendevreviewMerged openstack/nova master: Drop unused method  https://review.opendev.org/c/openstack/nova/+/92768008:01
opendevreviewJonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on  https://review.opendev.org/c/openstack/nova/+/95565708:09
Guest23994sean-k-mooney can we agree on the rfe for waiting for ovn-controller at live migration? https://bugs.launchpad.net/neutron/+bug/206971808:25
Guest23994The submitted patches are only as POC, of cause some adjustments are needed. But I wanted first to discuss if the approach is fine for you.08:26
sthoffmann[m]Sorry, messed up my nick.08:43
opendevreviewMarkus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption  https://review.opendev.org/c/openstack/nova/+/92632608:45
opendevreviewLajos Katona proposed openstack/os-vif stable/2024.1: Do not add taps in trunk bridges to the dead vlan  https://review.opendev.org/c/openstack/os-vif/+/95749009:16
opendevreviewLajos Katona proposed openstack/os-vif stable/2024.1: OVS Trunk: Add bridge_name to external_ids  https://review.opendev.org/c/openstack/os-vif/+/95749109:16
jssfrsean-k-mooney, melwitt, I updated the vTPM patch. I find the version check implementation a bit clunky, but it's the variant which I found causes least impact in unittesting. A quick feedback on whether that's the right direction or you'd prefer something else would be appreciated: https://review.opendev.org/c/openstack/nova/+/955657/3/nova/virt/libvirt/driver.py#59009:45
jssfrand https://review.opendev.org/c/openstack/nova/+/955657/3/nova/virt/libvirt/driver.py#168909:45
sean-k-mooneyjssfr: ya its because we do the version checks for the most part in driver.py rather then in guest.py10:37
jssfrI did that now, too :)10:37
jssfr(see the linked lines, I hope linking to the lines worked)10:37
sean-k-mooneyjssfr: but your following the pattern so that fine. as i said i woudl be tempted to take flags instead of keep_vtpm as teh partameter10:37
jssfrohh10:38
jssfrlike the actual flags passed to the undefine command?10:38
sean-k-mooneyya10:38
jssfrhmmm10:38
jssfrI think I like my way better ;)10:38
jssfr(in particular because there's also some error handling around undefineFlags not being available in that method)10:38
sean-k-mooneywe dont need too but it will be more flexable going forward10:38
jssfrack10:38
sean-k-mooneyright this way we can keep the guest.py code pretty dumb i.e. just passing through the calls to libvirt10:39
sean-k-mooneyand keep the busisness logic for checkign if the flags are supprot external where its used10:39
jssfrdo I need to somehow link the launchpad bug in the commit message or something?10:40
sean-k-mooneyam that is perfered `Closes-Bug: #<bug number>10:41
sean-k-mooney`10:41
opendevreviewJonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on  https://review.opendev.org/c/openstack/nova/+/95565710:41
jssfrdone10:41
sean-k-mooneyif you do it in that formate with teh # gerrit will make it a hyperlink ot the right place10:41
jssfrneat!10:41
sean-k-mooneyi have targeted the bug to all the stable branches. if its backported that far you could bring it to unmainteained however you will likely problems with the aviable libvirt version as you go older10:43
sean-k-mooneywell it wont break because your doing the check it just wont be functional either10:44
sean-k-mooneyi have assigned the bug to you for master and then we can update the others based on who does the backport later10:45
jssfrthanks!10:45
jssfras I mentioned, we'll likely backport to 2024.1 on our own, so you could assign that to me, too.10:46
sean-k-mooneyif you want to do that upstream you just need to cherry pick the same patch to each branch in turn so i have assigne all of them to you for now but you can clear that if you dont end up workign on it10:52
sean-k-mooneywe dont really use the assinee filed for much10:52
sean-k-mooneyits at most "this person might be working on it"10:53
sean-k-mooneyso feel free to udpate it as needed10:53
opendevreviewJonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on  https://review.opendev.org/c/openstack/nova/+/95565711:21
opendevreviewMerged openstack/nova master: Run nova-api and -metadata in threaded mode  https://review.opendev.org/c/openstack/nova/+/95195711:53
opendevreviewMarkus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption  https://review.opendev.org/c/openstack/nova/+/92632613:00
opendevreviewBalazs Gibizer proposed openstack/nova master: DNM: Force librbd1 19.2.0 to fix ceph job  https://review.opendev.org/c/openstack/nova/+/95495613:39
gibidoes anybod have history about why we have address space limitation set for qemu-img info calls in https://github.com/openstack/nova/blob/e39bac965a2d947d32325446ef8427dd5f6c85c7/nova/privsep/qemu.py#L34-L36 ? And why we choose the 1G limit? It seems that with ceph 19.2.1 with luks v1 encrypted volume when that volume is resized the qemu-img info fails as due to the memory 1G limit. If I bump it with 13:43
gibi5MB then the qemu-img info succeeds. Is it a valid solution to bump the limit? Should we not hardoce a limit but make it configurable?13:43
gibiref https://bugs.launchpad.net/nova/+bug/2116852 and https://bugzilla.redhat.com/show_bug.cgi?id=238827113:43
dansmithgibi: I'm sure it's a safety limit and I wouldn't think bumping it for everything would make sense13:48
dansmithyou literally bump it to 1.005G and it works?13:48
gibiyepp13:48
gibiI tried to see how close we were the limit in 19.2.0 but I cannot roll back to that version any more locally13:49
dansmithso tools like this have to work pretty hard to not load the entire image into memory so I think it's probably a good idea for us to have that limit13:49
gibiyeah, I affraid that this is a wack a mole just bumping the limit blindly13:50
dansmithand TBH, I'm surprised that it needs to be 1G  to run qemu-img info, which probably means a bug that this is catching13:50
gibithe Ceph folks so far was responsive in the bz. So hopefully they can come up with a way to troubleshoot it further13:50
dansmithunless there's a very large extent size on a volume or something, causing us to buffer that large13:50
dansmithI would think making it configurable would be a good idea13:51
jssfrand/or a non-raw format13:51
dansmithjssfr: it's hard but not impossible to support the non-raw formats in constant memory, but that's an easy place for bugs to creep in of course13:52
jssfryep.13:52
dansmithI was thinking more the LUKS chunk size, since this is encrypted13:52
jssfrah, I was thinking rbd block size13:52
dansmithbut either way, that sort of thing is exactly why having a limit is a good idea13:52
dansmithcould be either and/or some relation between rbd and LUKS here13:52
jssfr(which is typically 4 MiB. if you make it read 256 different blocks, mix in some librbd caching...)13:52
jssfragreed, limits good.13:53
jssfr(in particular when remembering why that qemu-info call is there in the first place.)13:53
jssfr(ah the fun of rolling out fixes for that CVE while in a train to a customer meeting :-))13:53
opendevreviewBalazs Gibizer proposed openstack/nova master: DNM: Reproduce bug/2116852  https://review.opendev.org/c/openstack/nova/+/95741913:57
opendevreviewBalazs Gibizer proposed openstack/nova stable/2024.2: DNM: Reproduce bug/2116852 with decreasing mem limit  https://review.opendev.org/c/openstack/nova/+/95754114:04
gibilet see how close we are to the 1G limit on Jammy with Ceph 17 ^^14:05
sean-k-mooneygibi: i think any limit like that shoudl really be configureabl and not hard coded14:11
sean-k-mooneyi dont recall the history but im i also kidn of agree that we dont want to kust keep bumping it either14:12
sean-k-mooneypersonally i would make that and the cpu times config options, leave the time as is and bump the memory to maybe 2-4G14:13
sean-k-mooneygibi: the thing im wonderingis we are setting adress_space14:14
sean-k-mooneyis that what we actully creare about or do we care about resident memory limit14:14
sean-k-mooneyif qemu-info uses 10TB of adress space but never uses more then 100MB of commit memory that perficly fine so we myigh be setting the wrong limit14:15
sean-k-mooneyhum https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/processutils.py#L125-L13414:17
sean-k-mooneyso https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/prlimit.py#L25-L68 prlimti supprot limiting on RSS14:18
sean-k-mooneythat actully what we likely care about14:19
sean-k-mooneyso we shoudl likely be using resident_set_size instead of of adress_space here https://github.com/openstack/nova/blob/e39bac965a2d947d32325446ef8427dd5f6c85c7/nova/privsep/qemu.py#L3614:19
sean-k-mooneygibi: if i recall when we were looking at this there was some refactoring happeing invovlg moving to differnt stackless coretine implemations and how they used allcoators so while that may have increase memrory usage my supisiton is it may have increase adresssapce usage but not nessisarly RSS14:22
sean-k-mooneygibi: this is where we first added this https://github.com/openstack/nova/commit/068d851561addfefb2b812d91dc2011077cb6e1d  for https://bugs.launchpad.net/nova/+bug/144906214:26
sean-k-mooneygibi:  so we added it to wrkaournd bugs in qemu-img14:26
sean-k-mooneyi also agree with dan that qemu-img should not need that much memroy in genreal so before bumping the limit i would move it form adress space to rss and see if that is enough14:30
opendevreviewBalazs Gibizer proposed openstack/nova master: [vncproxy]Handle ssl.wrap_socket removal in py312  https://review.opendev.org/c/openstack/nova/+/95591515:02
opendevreviewBalazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor  https://review.opendev.org/c/openstack/nova/+/95266615:02
opendevreviewMarkus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption  https://review.opendev.org/c/openstack/nova/+/92632615:26
opendevreviewMarkus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption  https://review.opendev.org/c/openstack/nova/+/92632615:47
opendevreviewMarkus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption  https://review.opendev.org/c/openstack/nova/+/92632615:48
dansmithmelwitt: thanks for hitting that image encryption one.. meant to ping you19:26
melwittnp. I wondered why it didn't start gate jobs, looks like it Depends-On a cinder change that isn't approved yet19:48

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