Sender | Message | Time |
---|---|---|
4 Sep 2023 | ||
osnyx (he/him) | 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. | 12:34:01 |
osnyx (he/him) | If we decide to go with one of the PRs, there's another thought: m1cr0man has implemented the run exclusions using systemd, citing a reduction of module complexity. I do agree with the general goal, we need to consider what kind of complexity we mean here. When it comes to understanding and reading what the module does to be able to maintain it, it's not just about the number and variety of involved software components but also about their scoping and the mental model presented by their interface. | 12:47:11 |
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.ioThe 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.orgWhether 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.ioI 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.orgI'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.ioUnderstandable | 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.orgOne 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.orgIf 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.ioAs 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 |