| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-14 | |||
| 19:39:34 | sean-k-mooney | but ya htat alot more then typical | |
| 19:40:04 | sean-k-mooney | i feel like they update the ui agian. not that im complaining | |
| 21:28:13 | opendevreview | Merged openstack/os-vif stable/2024.2: Do not add taps in trunk bridges to the dead vlan https://review.opendev.org/c/openstack/os-vif/+/952815 | |
| 23:13:47 | gmaan | yeah, I have seen 3 digit only few times. | |
| #openstack-nova - 2025-08-15 | |||
| 00:25:37 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 02:44:05 | opendevreview | Merged openstack/os-vif stable/2024.2: OVS Trunk: Add bridge_name to external_ids https://review.opendev.org/c/openstack/os-vif/+/952778 | |
| 04:48:16 | opendevreview | Merged openstack/nova master: Run nova-next with n-sch in threading mode https://review.opendev.org/c/openstack/nova/+/948450 | |
| 06:11:55 | opendevreview | Merged openstack/nova stable/2024.1: Use dict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/955305 | |
| 07:22:38 | gibi | melwitt: dansmith: replied in the vtpm series https://review.opendev.org/c/openstack/nova/+/941483/21#message-f8bc46bbe27eeb78f1ec79040932d9e3fa2db062 | |
| 08:01:26 | opendevreview | Merged openstack/nova master: Drop unused method https://review.opendev.org/c/openstack/nova/+/927680 | |
| 08:09:20 | opendevreview | Jonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657 | |
| 08:25:42 | Guest23994 | sean-k-mooney can we agree on the rfe for waiting for ovn-controller at live migration? https://bugs.launchpad.net/neutron/+bug/2069718 | |
| 08:26:32 | Guest23994 | The 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:43:59 | sthoffmann[m] | Sorry, messed up my nick. | |
| 08:45:23 | opendevreview | Markus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption https://review.opendev.org/c/openstack/nova/+/926326 | |
| 09:16:20 | opendevreview | Lajos 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/+/957490 | |
| 09:16:21 | opendevreview | Lajos Katona proposed openstack/os-vif stable/2024.1: OVS Trunk: Add bridge_name to external_ids https://review.opendev.org/c/openstack/os-vif/+/957491 | |
| 09:45:11 | jssfr | sean-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#590 | |
| 09:45:23 | jssfr | and https://review.opendev.org/c/openstack/nova/+/955657/3/nova/virt/libvirt/driver.py#1689 | |
| 10:37:07 | sean-k-mooney | jssfr: ya its because we do the version checks for the most part in driver.py rather then in guest.py | |
| 10:37:25 | jssfr | I did that now, too :) | |
| 10:37:39 | jssfr | (see the linked lines, I hope linking to the lines worked) | |
| 10:37:50 | sean-k-mooney | jssfr: but your following the pattern so that fine. as i said i woudl be tempted to take flags instead of keep_vtpm as teh partameter | |
| 10:38:05 | jssfr | ohh | |
| 10:38:14 | jssfr | like the actual flags passed to the undefine command? | |
| 10:38:19 | sean-k-mooney | ya | |
| 10:38:22 | jssfr | hmmm | |
| 10:38:24 | jssfr | I think I like my way better ;) | |
| 10:38:40 | sean-k-mooney | we dont need too but it will be more flexable going forward | |
| 10:38:40 | jssfr | (in particular because there's also some error handling around undefineFlags not being available in that method) | |
| 10:38:57 | jssfr | ack | |
| 10:39:21 | sean-k-mooney | right this way we can keep the guest.py code pretty dumb i.e. just passing through the calls to libvirt | |
| 10:39:38 | sean-k-mooney | and keep the busisness logic for checkign if the flags are supprot external where its used | |
| 10:40:30 | jssfr | do I need to somehow link the launchpad bug in the commit message or something? | |
| 10:41:00 | sean-k-mooney | am that is perfered `Closes-Bug: #<bug number> | |
| 10:41:02 | sean-k-mooney | ` | |
| 10:41:29 | opendevreview | Jonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657 | |
| 10:41:31 | jssfr | done | |
| 10:41:32 | sean-k-mooney | if you do it in that formate with teh # gerrit will make it a hyperlink ot the right place | |
| 10:41:44 | jssfr | neat! | |
| 10:43:54 | sean-k-mooney | i 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 older | |
| 10:44:13 | sean-k-mooney | well it wont break because your doing the check it just wont be functional either | |
| 10:45:33 | sean-k-mooney | i have assigned the bug to you for master and then we can update the others based on who does the backport later | |
| 10:45:53 | jssfr | thanks! | |
| 10:46:20 | jssfr | as I mentioned, we'll likely backport to 2024.1 on our own, so you could assign that to me, too. | |
| 10:52:36 | sean-k-mooney | if 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 it | |
| 10:52:47 | sean-k-mooney | we dont really use the assinee filed for much | |
| 10:53:11 | sean-k-mooney | its at most "this person might be working on it" | |
| 10:53:24 | sean-k-mooney | so feel free to udpate it as needed | |
| 11:21:05 | opendevreview | Jonas Schäfer proposed openstack/nova master: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/955657 | |
| 11:53:38 | opendevreview | Merged openstack/nova master: Run nova-api and -metadata in threaded mode https://review.opendev.org/c/openstack/nova/+/951957 | |
| 13:00:28 | opendevreview | Markus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption https://review.opendev.org/c/openstack/nova/+/926326 | |
| 13:39:07 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: Force librbd1 19.2.0 to fix ceph job https://review.opendev.org/c/openstack/nova/+/954956 | |
| 13:43:11 | gibi | does 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:17 | gibi | 5MB 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:28 | gibi | ref https://bugs.launchpad.net/nova/+bug/2116852 and https://bugzilla.redhat.com/show_bug.cgi?id=2388271 | |
| 13:48:14 | dansmith | gibi: I'm sure it's a safety limit and I wouldn't think bumping it for everything would make sense | |
| 13:48:25 | dansmith | you literally bump it to 1.005G and it works? | |
| 13:48:36 | gibi | yepp | |
| 13:49:09 | gibi | I tried to see how close we were the limit in 19.2.0 but I cannot roll back to that version any more locally | |
| 13:49:42 | dansmith | so 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 limit | |
| 13:50:15 | gibi | yeah, I affraid that this is a wack a mole just bumping the limit blindly | |
| 13:50:17 | dansmith | and TBH, I'm surprised that it needs to be 1G to run qemu-img info, which probably means a bug that this is catching | |
| 13:50:53 | gibi | the Ceph folks so far was responsive in the bz. So hopefully they can come up with a way to troubleshoot it further | |
| 13:50:58 | dansmith | unless there's a very large extent size on a volume or something, causing us to buffer that large | |
| 13:51:23 | dansmith | I would think making it configurable would be a good idea | |
| 13:51:26 | jssfr | and/or a non-raw format | |
| 13:52:16 | dansmith | jssfr: 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 course | |
| 13:52:24 | jssfr | yep. | |
| 13:52:31 | dansmith | I was thinking more the LUKS chunk size, since this is encrypted | |
| 13:52:39 | jssfr | ah, I was thinking rbd block size | |
| 13:52:40 | dansmith | but either way, that sort of thing is exactly why having a limit is a good idea | |
| 13:52:54 | dansmith | could be either and/or some relation between rbd and LUKS here | |
| 13:52:59 | jssfr | (which is typically 4 MiB. if you make it read 256 different blocks, mix in some librbd caching...) | |
| 13:53:13 | jssfr | agreed, limits good. | |
| 13:53:21 | jssfr | (in particular when remembering why that qemu-info call is there in the first place.) | |
| 13:53:36 | jssfr | (ah the fun of rolling out fixes for that CVE while in a train to a customer meeting :-)) | |
| 13:57:36 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: Reproduce bug/2116852 https://review.opendev.org/c/openstack/nova/+/957419 | |
| 14:04:51 | opendevreview | Balazs Gibizer proposed openstack/nova stable/2024.2: DNM: Reproduce bug/2116852 with decreasing mem limit https://review.opendev.org/c/openstack/nova/+/957541 | |
| 14:05:13 | gibi | let see how close we are to the 1G limit on Jammy with Ceph 17 ^^ | |
| 14:11:28 | sean-k-mooney | gibi: i think any limit like that shoudl really be configureabl and not hard coded | |
| 14:12:22 | sean-k-mooney | i dont recall the history but im i also kidn of agree that we dont want to kust keep bumping it either | |
| 14:13:57 | sean-k-mooney | personally i would make that and the cpu times config options, leave the time as is and bump the memory to maybe 2-4G | |
| 14:14:16 | sean-k-mooney | gibi: the thing im wonderingis we are setting adress_space | |
| 14:14:35 | sean-k-mooney | is that what we actully creare about or do we care about resident memory limit | |
| 14:15:36 | sean-k-mooney | if 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 limit | |
| 14:17:35 | sean-k-mooney | hum https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/processutils.py#L125-L134 | |
| 14:18:56 | sean-k-mooney | so https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/prlimit.py#L25-L68 prlimti supprot limiting on RSS | |
| 14:19:10 | sean-k-mooney | that actully what we likely care about | |
| 14:19:40 | sean-k-mooney | so 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#L36 | |
| 14:22:54 | sean-k-mooney | gibi: 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 RSS | |
| 14:26:10 | sean-k-mooney | gibi: this is where we first added this https://github.com/openstack/nova/commit/068d851561addfefb2b812d91dc2011077cb6e1d for https://bugs.launchpad.net/nova/+bug/1449062 | |
| 14:26:36 | sean-k-mooney | gibi: so we added it to wrkaournd bugs in qemu-img | |
| 14:30:45 | sean-k-mooney | i 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 enough | |
| 15:02:38 | opendevreview | Balazs Gibizer proposed openstack/nova master: Warn on long task wait time for executor https://review.opendev.org/c/openstack/nova/+/952666 | |
| 15:02:38 | opendevreview | Balazs Gibizer proposed openstack/nova master: [vncproxy]Handle ssl.wrap_socket removal in py312 https://review.opendev.org/c/openstack/nova/+/955915 | |
| 15:26:45 | opendevreview | Markus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption https://review.opendev.org/c/openstack/nova/+/926326 | |
| 15:47:28 | opendevreview | Markus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption https://review.opendev.org/c/openstack/nova/+/926326 | |
| 15:48:19 | opendevreview | Markus Hentsch proposed openstack/nova master: Adapt to Cinder and Glance changes for image encryption https://review.opendev.org/c/openstack/nova/+/926326 | |
| 19:26:55 | dansmith | melwitt: thanks for hitting that image encryption one.. meant to ping you | |