Tuesday, 2025-07-22

*** mhen_ is now known as mhen01:49
*** tosky_ is now known as tosky07:33
opendevreviewStephen Finucane proposed openstack/pbr master: Do not use the onerror parameter in shutil.rmtree()  https://review.opendev.org/c/openstack/pbr/+/92480309:11
opendevreviewStephen Finucane proposed openstack/pbr master: Silence Python warnings  https://review.opendev.org/c/openstack/pbr/+/95470809:14
hberaud[m]dtantsur: Nice works, congrats. A side topic that you may want to heard of https://review.opendev.org/c/openstack/nova/+/94834009:14
hberaud[m]I just made some suggestions around releases notes on your both patches, else, LGTM09:32
dtantsurLooking now09:34
dtantsurhberaud[m]: not sure what you mean there: the green pool also does not shrink. It just matters less with lightweight green threads.09:35
dtantsurThe underlying greenpool has a resize method, but we don't seem to ever call it09:37
opendevreviewDmitry Tantsur proposed openstack/futurist master: Add DynamicThreadPoolExecutor that resizes itself  https://review.opendev.org/c/openstack/futurist/+/95521709:43
dtantsurhberaud[m]: here are some reno and docstrings improvements ^^^09:43
hberaud[m]ack thanks10:03
hberaud[m]perfect10:03
hberaud[m]I'd also suggest to add a release note there https://review.opendev.org/c/openstack/futurist/+/95547810:04
dtantsurhberaud[m]: it's not user-visible, the API is not exposed via public interfaces.10:05
dtantsurWhich behavior changes do you have in mind?10:05
hberaud[m]Indeed sorry10:05
hberaud[m]I was thinking about tombstone on the queue, causing all workers to eventually stop10:06
dtantsurYeah, but stop() is already only called in situations where a total stop is required. In all instances I could find, we iterate over all workers anyway.10:07
dtantsurSo unless I"m missing something important, it's not actually a change.10:07
hberaud[m]Yeah you are right10:07
hberaud[m]ignore my comment10:07
dtantsurTheJulia: btw we need to consider running our CI job on futurist.10:11
hberaud[m]dtantsur: concerning your previous request about pep8-incompatible recommendation, is it still relevant? Apparently you fixed it.11:38
dtantsurhberaud[m]: I have not, futurist still prefers W503 over W504, the former being pep8-incompatible11:43
hberaud[m]Ok, then I'll try to move to W50411:44
hberaud[m]I see many projects ignore both11:46
dtantsurheh11:46
hberaud[m]do you have a preference?11:46
hberaud[m]https://codesearch.opendev.org/?q=W503&i=nope&literal=nope&files=&excludeFiles=&repos=11:46
dtantsurW504 matches pep8, which is why it's my preference11:46
hberaud[m]ok, sold11:46
dtantsurHas anyone seen tox just hard hanging on start-up? Oo11:48
dtantsuris it for everyone or just me?11:49
hberaud[m]yeah, it hang on on requirements11:50
dtantsurneat11:51
dtantsurokay, so I'm splitting the properties per gibi request. But I'll wait a bit until I can run the unit tests locally before submitting.11:51
* dtantsur has lunch in the meantime11:51
opendevreviewHervĂ© Beraud proposed openstack/futurist master: prefer using flake8 W504 instead of W503  https://review.opendev.org/c/openstack/futurist/+/95559312:07
hberaud[m]dtantsur: it will impact your patch, either we merge yours first and then I go back with mine, or the contrary, its up to you12:08
hberaud[m]^12:08
dtantsurSigh, it will12:09
dtantsurhberaud[m]: I'd slightly prefer to get my series in first. I'm starting a long PTO on Friday.12:09
dtantsuror I can rebase the entire chain if you don't want to wait12:10
hberaud[m]Yeah sure no problem, I propose to go first with your patch, and I'll rework mine once done12:10
hberaud[m]No rush from my side12:10
dtantsurthx!12:10
opendevreviewMerged openstack/pbr master: Silence Python warnings  https://review.opendev.org/c/openstack/pbr/+/95470812:42
opendevreviewMerged openstack/pbr master: Do not use the onerror parameter in shutil.rmtree()  https://review.opendev.org/c/openstack/pbr/+/92480312:42
opendevreviewDmitry Tantsur proposed openstack/futurist master: Fix ThreadWorker.stop to stop only this worker  https://review.opendev.org/c/openstack/futurist/+/95547812:48
opendevreviewDmitry Tantsur proposed openstack/futurist master: Add DynamicThreadPoolExecutor that resizes itself  https://review.opendev.org/c/openstack/futurist/+/95521712:48
opendevreviewDmitry Tantsur proposed openstack/futurist master: Provide insights into the state of ThreadPoolExecutor  https://review.opendev.org/c/openstack/futurist/+/95559512:48
dtantsurhberaud[m], gibi, this is the chain now ^^^12:48
hberaud[m]ack12:52
TheJuliadtantsur: already considered/pondered on my end. I'm going to pin the stack size down, and even then we really don't *appear* to chew that much memory. I think it should, realistically, be fine in the grand scheme of things13:10
* dtantsur nods13:12
TheJuliadtantsur: I'm under no illusion there will be an increased footprint, but its the virtual which skyrockets due to the free memory allocations, not the actual resident amount.13:27
TheJulia(at least, when the default stack size is pinned down)13:28
gibidtantsur: ack thanks13:28
TheJuliadtantsur: eh, slightly closer to 8 minutes on the current rev, but generally I'll just let it keep going since it is still early on17:13
TheJuliabut overall, still seeming consistent and generally good17:14
TheJuliadtantsur: hovering right around 7:45 consistently18:05
TheJuliaSGTM18:05

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