| 4 Sep 2023 |
 m1cr0man | This really comes down to a question of maintenance in my head. Both add complexity in their own ways, and have other merits. To be honest, I'm stuck for time at the moment and I would gladly take the help on keeping the module functioning at the moment. If you are willing to help maintain this portion of the module Oliver, then I'm happy to see your pr merged 🙂 | 12:53:40 |
 raitobezarius (DECT 2128) | If we implement the solution in systemd, while it's true that the latency of getting those changes in systemd takes time, it does not prevent anyone running them inside of an organization :) | 12:53:46 |
| raitobezarius (DECT 2128) | I am biased either way as a systemd and NixOS developer and see the value of having this upstream rather than specialized here | 12:54:48 |
| raitobezarius (DECT 2128) | So don't take my opinion as a blocker or whatever | 12:55:06 |
 osnyx (he/him) | In reply to @raitobezarius:matrix.org
The question is for whom are you solving this such urgently? Whether this is urgent for NixOS upstream is partly your decision as the maintainers team (as a personal user I'd say yes as well), but the implementation I am doing for FlyingCircus. | 12:55:25 |
| raitobezarius (DECT 2128) | From my personal perspective as a NixOS developer, there's an appetite for anti concurrency for any systemd service honestly | 12:55:59 |
| raitobezarius (DECT 2128) | Giving a pass to ACME is probably fine because of the importance | 12:56:14 |
| raitobezarius (DECT 2128) | But I don't think we could accept the proliferation of this ad-hoc everywhere | 12:56:25 |
| raitobezarius (DECT 2128) | Hence my desire to solve it at the primitive level | 12:56:35 |
| raitobezarius (DECT 2128) | 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 (DECT 2128) | (of course I say this and microman is the maintainer of this subsystem) | 12:57:42 |
| raitobezarius (DECT 2128) | 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 (DECT 2128) | 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 (DECT 2128) | Also, I do see running this downstream as an extremely valuable way to gather feedback on systemd primitives and experience | 12:58:56 |
| raitobezarius (DECT 2128) | 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 (DECT 2128) | Large features like this are often blocked because everyone is paralyzed by it not being "finalized" | 12:59:20 |
| raitobezarius (DECT 2128) | 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 (DECT 2128) | 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 (DECT 2128) | 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 (DECT 2128) | 23.11 is basically done | 13:04:02 |
| raitobezarius (DECT 2128) | 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 (DECT 2128) | 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 (DECT 2128) | 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 |
