 | NixOS ACME / LetsEncrypt | 93 Members |
| Another day, another cert renewal | 43 Servers |
| NixOS ACME / LetsEncrypt | 93 Members |
| Another day, another cert renewal | 43 Servers |
| Sender | Message | Time |
|---|---|---|
| 4 Sep 2023 | ||
 osnyx (he/him) | In reply to @raitobezarius:matrix.orgDepending on whether the PR will progress again, you could take https://github.com/systemd/systemd/pull/27985#issuecomment-1621702189 as a starting point | 13:09:51 |
| osnyx (he/him) | In reply to @m1cr0man:m1cr0man.comAs I wrote in my comparison, the flock approach provides the concurrency guarantees in a broader scenario of cases. As most of you are worried of added complexity, in the end it's just a decision on which approach you as the maintainers (not just m1cr0man because of course you as the implementor understand what's happening there ;) )you feel more comfortable with and which you understand better. | 13:21:37 |
| osnyx (he/him) | When it comes to (not) modifying the service script, let me argue that my change barely counts as such a modification from the semantical level. It's just an optional wrapper around the otherwise unmodified service script. | 13:23:55 |
| osnyx (he/him) | My take on the "let's solve it with systemd unit options alone" approach is just the idea that we must be careful to not fall into the when all you want to use is a systemd-253 hammer, everything looks like a unit option hammer. It might be a hammer you know, but that hammer bight also just be adding things to the evergrowing list of interwoven systemd unit relationships… | 13:28:14 |
| osnyx (he/him) | But that's just one perspective on it, I'm not interested in NIH but just explaining and – if they turn out to be solid possibly defend – my implementation decisions (= | 13:29:43 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.orgSo can I read this as a clear "we'll postpone the fix until systemd is ready" from your side and you won't even merge the m1cr0man PR? Then I need to prepare myself for maintaining a downstream acme fork. If yes, can I rely on you to push this forward? | 13:33:52 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.org* So can I read this as a clear "we'll postpone the fix until systemd is ready" from your side and you won't even merge the m1cr0man PR? Then I need to prepare myself for maintaining a downstream acme fork. If yes, can I interpret this as you taking on to push this forward? | 13:41:35 |
 m1cr0man | I think your arguments are solid. I'm not on board for waiting for systemd to add features (and your hammer saying is the same reason why). Like I said if you're willing to just be around to take questions or PR fixes into that portion of the module, I'm happy to see your one merged. I do think it is more complicated but I can live with that if I'm not the only one that understands how it works. I would like you to copy over the test case I made though, to prevent future regressions | 13:54:12 |
 raitobezarius | In reply to @os:matrix.flyingcircus.ioI am not a blocker as said earlier | 13:54:31 |
| raitobezarius | I will let m1cr0man do the call for the ACME module | 13:54:42 |
| raitobezarius | It's their turf | 13:54:45 |
| m1cr0man | In reply to @raitobezarius:matrix.orgI understand but your arguments are also valid. | 13:54:56 |
| raitobezarius | Of course | 13:55:02 |
| raitobezarius | But | 13:55:04 |
| osnyx (he/him) | Good, because I read conflicting signals 😅 | 13:55:06 |
| raitobezarius | I'd rather focus on bringing the feature to systemd | 13:55:08 |
| raitobezarius | And let you folks figure out what you prefer to do here in Nixpkgs as long as you find an agreement :) | 13:55:19 |
| m1cr0man | Yeah I agree but no one in this room (afaik) has the skills or time to do so | 13:55:37 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.orgAs I said earlier, once this is ready I'll happily help with porting things over. | 13:55:38 |
| raitobezarius | In reply to @m1cr0man:m1cr0man.comI do have the time and skills to bring it to systemd ;) | 13:56:10 |
| raitobezarius | I mean, time, well, I can always find some in another dimension :) | 13:56:18 |
| raitobezarius | * I mean, time, well, I can always find some in another dimension :) | 13:56:21 |
| osnyx (he/him) | For my PR, I'll happily ad the missing tests, I just didn't want to put any more time into something struggling to get any traction. | 13:56:35 |
| raitobezarius | But I don't think it's reasonable to block indefinitely something on the hope of seeing it merged | 13:56:38 |
| m1cr0man | In reply to @raitobezarius:matrix.orgOh neat okay, I didn't realize 😅 | 13:56:48 |
| raitobezarius | But I cannot grasp the maintenance overhead merging this would create | 13:56:52 |
| m1cr0man | It's added complexity to the Acme units. I've been pretty adverse to feature additions because it creates new failure scenarios and it's already got crazy feature creep but in this instance it's pretty important to have a rate limit and I've seen the effects of it first hand. | 13:58:14 |
| osnyx (he/him) | In reply to @m1cr0man:m1cr0man.comThat's why I wanted to get another opinion of the team regarding not the only one that understands how it works. I try to get the tests in this week. | 13:59:31 |
| raitobezarius | I think it's fair that we set the "direction of the ACME module" to: we can welcome this feature and urge/usher into an era where systemd will provide it and we can decrease the complexity in the future | 14:05:46 |
| m1cr0man | I also want to upstream some stuff to Lego, so between the two hopefully complexity will fall over the next while. | 14:11:31 |