| 4 Sep 2023 |
 raitobezarius | From my personal perspective as a NixOS developer, there's an appetite for anti concurrency for any systemd service honestly | 12:55:59 |
| raitobezarius | Giving a pass to ACME is probably fine because of the importance | 12:56:14 |
| raitobezarius | But I don't think we could accept the proliferation of this ad-hoc everywhere | 12:56:25 |
| raitobezarius | Hence my desire to solve it at the primitive level | 12:56:35 |
| raitobezarius | Therefore I don't think there's an emergency beyond ACME large users (you and some folks, including me) | 12:57:16 |
 osnyx (he/him) | AFAIK keeping patches on NixOS modules downstream is not that easy, correct me if I'm wrong. Additionally to being good citizens in the NixOS community and trying to wor upstream-first for apparent bugs, I'd of course also want to prevent having to maintain a downstream module fork. | 12:57:38 |
| raitobezarius | (of course I say this and microman is the maintainer of this subsystem) | 12:57:42 |
| raitobezarius | In reply to @os:matrix.flyingcircus.io
AFAIK keeping patches on NixOS modules downstream is not that easy, correct me if I'm wrong. Additionally to being good citizens in the NixOS community and trying to wor upstream-first for apparent bugs, I'd of course also want to prevent having to maintain a downstream module fork. I do keep 20ish patches for my own infra for a large infra, I am not sure if you are targeting stable or unstable | 12:58:10 |
| raitobezarius | Surely having a custom systemd will set you for some pain if you don't have large build farm or too regular builds | 12:58:27 |
| raitobezarius | Also, I do see running this downstream as an extremely valuable way to gather feedback on systemd primitives and experience | 12:58:56 |
| raitobezarius | Ultimately paving the way to push it upstream | 12:59:04 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.org
Hence my desire to solve it at the primitive level I'm supportive of that. But as I said, I won't be the one writing that C code, but could be the one solving this as I had done in the PR with the lowest footprint I could do. | 12:59:13 |
| raitobezarius | Large features like this are often blocked because everyone is paralyzed by it not being "finalized" | 12:59:20 |
| raitobezarius | In reply to @os:matrix.flyingcircus.io
I'm supportive of that. But as I said, I won't be the one writing that C code, but could be the one solving this as I had done in the PR with the lowest footprint I could do. Understandable | 12:59:33 |
| raitobezarius | Either case, I just wanted to put on the balance the both (valid IMHO) approaches | 13:00:25 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.org
Giving a pass to ACME is probably fine because of the importance One thing I could have proposed as a compromise would've been adding some custom hooks into the service logic which we could fill with locking logic downstream. But maybe we can get a proper solution in in-time. | 13:01:26 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.org
Therefore I don't think there's an emergency beyond ACME large users (you and some folks, including me) If it was an emergency, I wouldn't be targeting the next stable release ;) | 13:01:55 |
 m1cr0man | The closest we get to a systemd based solution is my PR. My real question here Oliver is, is there something in your PR that my one does not provide at a functional level? Personally, adding complexity to the renew script itself is something I actively try to avoid. I also add tests for any new features to avoid future regressions if someone attempts to optimise the module.
As for a custom hook - if that's acceptable for your case you actually can do that already 😁 just create a service which is requiredby + before the renew service to handle the lock | 13:02:51 |
| raitobezarius | In reply to @os:matrix.flyingcircus.io
If it was an emergency, I wouldn't be targeting the next stable release ;) As a release manager, 24.11 is very soon in my brain :p | 13:03:49 |
| raitobezarius | 23.11 is basically done | 13:04:02 |
| raitobezarius | 24.05 will start soon (tm) | 13:04:10 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.org
I do keep 20ish patches for my own infra for a large infra, I am not sure if you are targeting stable or unstable We're running stable releases. I am not sure whether we'd want all of our machines to run with a canary-systemd (🥶) but we might be able to do this for one of the few especially domain-rich machines – if there is a perspective of this helping things going upstream soonish. | 13:04:33 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.org
23.11 is basically done Is there anything I could've done better for upstreaming? On the one hand I was eager to implement something already i May, on the other hand I went the extra mile to go through your alternative proposals first. | 13:06:12 |
| raitobezarius | Yeah I think the issue is that systemd development is faster with someone who is close to systemd, I had the same issues and decided to bite the bullet to avoid things lingering for too long | 13:06:50 |
| raitobezarius | It's hard to do better than what you have done and I am happy you went through all the thousands cuts | 13:07:09 |
| raitobezarius | I'd be happy taking your concurrency subject to Poettering and co to get it merged | 13:07:39 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.org
It's hard to do better than what you have done and I am happy you went through all the thousands cuts Good to hear, because I know a person who wasn't that intrigued that I eagerly jumped through all those hoops ^^ | 13:08:06 |
| raitobezarius | The problem is having someone responsive for the C bits but I can try to pick up the pieces and see what is left to do | 13:08:07 |
| raitobezarius | In reply to @os:matrix.flyingcircus.io
Good to hear, because I know a person who wasn't that intrigued that I eagerly jumped through all those hoops ^^ It's usually very hard to please folks in open source development | 13:08:31 |
| raitobezarius | In reply to @os:matrix.flyingcircus.io
We're running stable releases. I am not sure whether we'd want all of our machines to run with a canary-systemd (🥶) but we might be able to do this for one of the few especially domain-rich machines – if there is a perspective of this helping things going upstream soonish. If I have something on this end, I will be sure to ping you as a guinea pig :p | 13:09:00 |
