[00:03:54]
<Yunohost Git/Infra notifications> [issues] kutsaltotem opened [issue #2388](https://github.com/YunoHost/issues/issues/2388): google dns error
[00:03:54]
<Yunohost Git/Infra notifications> [issues] kutsaltotem labeled :space_invader: bug on [issue #2388](https://github.com/YunoHost/issues/issues/2388): google dns error
[00:44:51]
<Émy - OniriCorpe> > <@yunohostinfra:matrix.org> [issues] kutsaltotem labeled :space_invader: bug on [issue #2388](https://github.com/YunoHost/issues/issues/2388): google dns error
YunoHost is using a [2 years old lexicon version](https://github.com/AnalogJ/lexicon/releases/tag/v3.11.2 ), maybe it’s time to update it?
[04:52:23]
<Yunohost Git/Infra notifications> [issues] chri2 [commented](https://github.com/YunoHost/issues/issues/2377#issuecomment-2103860000) on [issue #2377](https://github.com/YunoHost/issues/issues/2377) extend manifest.toml [resources.apt] section to allow _interactive_ installation of dependencies: Had just this thought: Wouldnt it be possible to automatically install a dpkg without configuring (leaving it unconfigu...
[13:10:45]
<selfhoster1312> something is not clear in my mental model of Yunohost: moulinette CLI does not go through the long-running daemon, right? so any CLI operation must clearly mark yunohost-api caching as stale?
[13:19:32]
<selfhoster1312> is that why there's so little caching, because it would be trickier with the different entry points?
[13:37:38]
<Aleks (he/him/il/lui)> yes
[13:38:01]
<Aleks (he/him/il/lui)> on the medium/long-term we are starting to discuss having the CLI as an API client
[13:38:12]
<Aleks (he/him/il/lui)> i.e. maybe rewriting/getting rid of moulinette by using FastAPI instead
[13:42:29]
<selfhoster1312> that sounds reasonable, does FASTAPI provide a CLI->Web translation layer? i can see they have a CLI library but i don't read that it would be for building a Web API client (but something more like moulinette) ?
[13:43:30]
<selfhoster1312> otherwise, is it reasonable to write a moulinette CLI->Web interface?
[13:44:10]
<selfhoster1312> personally i might be more inclined to have a Redis cache running for all programs who need this global state, was that ever considered?
[13:44:47]
<Aleks (he/him/il/lui)> idk i never really digged into redis
[13:45:30]
<selfhoster1312> well i'm not a fan, i think a better architecture would be a *single* yunohost-api daemon which holds all state, but since there's yunohost CLI, ssowat and yunohost-portal-api, maybe having a lightweight key-value RAM store makes sense
[13:46:01]
<Aleks (he/him/il/lui)> honestly right now caching is less an issue than the fact that we still have some sort of annoying lock mechanism .... or rather maybe the API is a single worker ? So right now imho the priority on this topic is having a proper way to e.g. know what operation is running when opening the webadmin rather than just "The lock is being taken right now"
[13:46:02]
<selfhoster1312> it's like really lightweight, and since we're deprecating metronome by default in next release we shouldn't use more memory than before
[13:46:04]
<Aleks (he/him/il/lui)> (ie during long backups)
[13:46:14]
<Aleks (he/him/il/lui)> or being able to stream logs to multiple people logged in on the webadmin
[13:46:51]
<Aleks (he/him/il/lui)> cf https://github.com/YunoHost/yunohost/pull/1663 for example (though idk if that's the right design)
[13:47:03]
<selfhoster1312> that sounds reasonable! i assumed all this was long solved ^^"
[13:47:33]
*selfhoster1312 taking a look
[13:48:58]
<selfhoster1312> so zeromq means you can have mutliple subscribers to the same channel, correct? but it doesn't mean (in this PR) that you know who/what is holding the lock, right?
[13:49:17]
<Aleks (he/him/il/lui)> yes that's unrelated i think
[13:49:37]
<Aleks (he/him/il/lui)> thouuugh i was thinking about having some sort of route or state of "what's the current modifying operation"
[13:49:40]
<Aleks (he/him/il/lui)> i don't know where i ended up with this
[13:49:44]
<Aleks (he/him/il/lui)> it was a long time ago
[13:50:25]
<Aleks (he/him/il/lui)> ah there's https://github.com/YunoHost/moulinette/pull/333 too
[13:52:01]
<Aleks (he/him/il/lui)> there's an `.emit_operation_start` in the yunohost PR
[13:52:04]
<Aleks (he/him/il/lui)> and `_end`
[13:52:13]
<Aleks (he/him/il/lui)> dunno if i'm satisfied with this
[13:52:29]
<selfhoster1312> i'm not familiar with zeromq and its parlance but all that looks good
[13:52:37]
<Aleks (he/him/il/lui)> right now a CLI operation could get killed and never send the emit_operation_end
[13:53:00]
<selfhoster1312> correct
[13:53:23]
<selfhoster1312> but in the locking code we should save the PID / operation ID holding the lock
[13:53:26]
<selfhoster1312> so that can be checked periodically
[13:54:12]
<selfhoster1312> (operation ID would be for web UI operation since they have the same PID every time as the daemon)
[13:54:37]
<Aleks (he/him/il/lui)> anyway, back to redis : honestly i don't know what would be the goal of having "more caching" .. right now imho the biggest performances issues are related to the fact that, for example, the regen conf takes ages because it needs to call `yunohost` cli from inside the bash script, and each call takes 2-3 seconds (on an RPi for example), and the biggest performance improvement by far would be having the CLI-being-an-API-client ... but this is like a major project which won't see the light (=being actually released) before at least Trixie, so at least 2 years i guess
[13:55:01]
<Aleks (he/him/il/lui)> so **then** we can do some other profiling and i don't think ldap queries are gonna be the biggest bottleneck idk
[13:55:49]
<selfhoster1312> it's not just LDAP queries i want to cache :)
[13:55:55]
<selfhoster1312> although those modify_ext_s were tempting tbh
[13:56:30]
<selfhoster1312> running the tests i'm noticing domain_config_get/domain_list gets called *many* times when adding a domain
[13:56:42]
<selfhoster1312> there's supposed to be some caching logic but it doesn't seem to work?
[13:57:32]
<selfhoster1312> haven't dug really but i have good hopes to make tests faster (already removed >10s by having a function to add several domains and only regen conf 1 time)
[13:57:37]
<Aleks (he/him/il/lui)> ah yeah the config panel stuff is a mess
[13:58:13]
<Aleks (he/him/il/lui)> (in terms of perfs)
[13:58:23]
<selfhoster1312> well 'ill try to do a little caching and see
[14:49:06]
<selfhoster1312> so i'm down from 51s to 21s for this setup_module without caching, just by removing some regen_conf... i think it's not bad? i'll try see if i can polish this into a PR
[14:49:23]
<selfhoster1312> :q
[15:39:29]
<Émy - OniriCorpe> > <@oniricorpe:im.emelyne.eu> YunoHost is using a [2 years old lexicon version](https://github.com/AnalogJ/lexicon/releases/tag/v3.11.2 ), maybe it’s time to update it?
pspspspsps aleks pspspsps
[15:58:06]
<Yunohost Git/Infra notifications> [yunohost] selfhoster1312 opened [pull request #1830](https://github.com/YunoHost/yunohost/pull/1830): WIP: Test optimizations
[16:33:40]
<tituspijean> > <@oniricorpe:im.emelyne.eu> pspspspsps aleks pspspsps
I've had a look at the features released since then, and there's support for TOTP, which might requires us to expand the CLI and webadmin?
[16:33:41]
<Yunohost Git/Infra notifications> [yunohost] OniriCorpe approved [pull request #1829](https://github.com/YunoHost/yunohost/pull/1829#pullrequestreview-2050442105) Translations update from Weblate
[16:33:49]
<Yunohost Git/Infra notifications> [yunohost] OniriCorpe merged [pull request #1829](https://github.com/YunoHost/yunohost/pull/1829): Translations update from Weblate
[16:33:49]
<Yunohost Git/Infra notifications> [yunohost] OniriCorpe pushed 17 commits to dev ([63a629200b42...21a157e2e7ce](https://github.com/YunoHost/yunohost/compare/63a629200b42...21a157e2e7ce))
[16:33:54]
<Yunohost Git/Infra notifications> [yunohost/dev] Translated using Weblate (Indonesian) Currently translated at 49.5% (388 of 783 strings) Translation: YunoHost/core Tr... - OniriCorpe
[16:46:02]
<Yunohost Git/Infra notifications> 🏗️ Starting build for yunohost/11.2.11.3+202405101645 for bullseye/unstable/all ...
[16:47:58]
<Yunohost Git/Infra notifications> ✔️ Completed build for yunohost/11.2.11.3+202405101645 for bullseye/unstable/all.
[18:36:39]
<selfhoster1312> 174.14s (cold run) or 109.43s (warm run) on branch bookworm
69.34s (cold run) or 55.52s (warm run) on branch test-optimization
[18:36:41]
<selfhoster1312> https://i.pinimg.com/originals/49/5b/ca/495bcab38cdf4eda3eda7c915508077f.jpg
[18:37:07]
<selfhoster1312> https://xmpp-upload.kl.netlib.re/upload/jX1PM6GvLYo6227/8f375aa0-aa32-475e-a901-a435b769951e.png
[18:37:35]
<selfhoster1312> i think that's enough for one day :) :)
[18:38:51]
<selfhoster1312> buuut to be fair there's a way we can gain *A LOT*
different tests use differnet domains/users, if we can do a single post-install, snapshot the image and then start the test without any setup/teardown step
[20:43:35]
<Yunohost Git/Infra notifications> [yunohost] tituspijean [commented](https://github.com/YunoHost/yunohost/pull/1759#issuecomment-2105247915) on [issue #1759](https://github.com/YunoHost/yunohost/pull/1759) Draft: Bullseye->Bookworm migration: I have just upgraded a server from YunoHost 11.2.11.3 to 12 after following the instructions of the first message. Migr...