| 4 Sep 2023 |
 osnyx (he/him) | Building a component that presents the clear abstraction "I am doing locking and exclusion" can be treated just by its promised functionality at superficial reading. Only when there are clues that it's actually the locking internals that are problematic, the internal component's implementation needs to be read and understood as well.
The solution by m1cr0man works well, too, but we might face the danger of the additional systemd unit parameters getting lost in the noise of the already present multitude of systemd unit parameters of acme units. | 12:51:09 |
 raitobezarius | In reply to @os:matrix.flyingcircus.io
TL;DR: Wanting to solve the acme generation concurrency issues with systemd is a nice approach, but implies leaving the issue unresolved for at least a year, if not longer. It is unclear whether the required mechanisms will ever be introduced to systemd, who's taking care of achieving this, and when this might happen. The question is for whom are you solving this such urgently? | 12:53:13 |
 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 | 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 | 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 | 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 | 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 |
