| 17 Jun 2021 |
 @grahamc:nixos.org | is before or after the right enum values? is there value in having a before-and-after? | 11:45:26 |
 hexa | after=localfs.target, before=myservice.service | 11:46:32 |
| hexa | like you could really make sure the service never goes into a failed state if that worked out | 11:47:02 |
| hexa | but you probably only can affect things post network(-online).target anyway, so that may be moot | 11:47:28 |
| @grahamc:nixos.org | I don't think that is the design srhb has mentioned | 11:53:52 |
 srhb | I was thinking something that only knows about activation, yeah, so entirely morph-side. | 11:54:12 |
| @grahamc:nixos.org | before / after in the context of "before or after activation" | 11:54:19 |
| hexa | oh | 11:55:22 |
| hexa | I'm in the pre-activation camp, not entirely sure of a use case when you'd want post-activation | 11:58:00 |
| @grahamc:nixos.org | well | 11:59:55 |
| @grahamc:nixos.org | I personally find it useful for the users that own the secrets to exist when the secrets are uploaded | 12:00:20 |
| @grahamc:nixos.org | also useful to use tmpfiles.d to create the directories they're in, otherwise morph will create the directory and it'll be owned by root, iirc | 12:02:49 |
| srhb | "post" is what previous nixops users tend to expect, and provides consistency with users, units etc., while morph has always been "pre" and left it up to the user to get consistency, yeah. | 12:03:13 |
| @grahamc:nixos.org | one totally valid option is to say "Well, this is just what morph does, if you want something different you're looking for a different tool" | 12:04:21 |
| srhb | Once we get into hook territory (check some state on remote machine before doing $foo) I feel less confident giving "this will definitely get merged"-advice of the cuff :) | 12:04:36 |
| @grahamc:nixos.org | (though in that case I would recommend deleting secrets owned by non-root users) | 12:04:45 |
| @grahamc:nixos.org | * (though in that case I would recommend deleting support for secrets owned by non-root users) | 12:04:50 |
| srhb | I think pre/post-activation is totally within scope. | 12:04:59 |
| srhb | I think the other things are too, but that's just not something I want to confidently say "this'll get merged" about :) | 12:05:15 |
| srhb | And have someone be very sad when it doesn't immediately. 😅 | 12:05:36 |
| hexa | seems you two got this topic handled well, and my understanding was quite a bit lacking | 12:06:10 |
| @grahamc:nixos.org | I'm actually less sure! | 12:06:31 |
| srhb | It's always a little sad when I participate and confuse people more. 😅 | 12:06:50 |
| @grahamc:nixos.org | like maybe secrets are just too complicated to implement as part of morph itself and have a coherent / complete story | 12:07:03 |
| @grahamc:nixos.org | In reply to @grahamc:nixos.org
one totally valid option is to say "Well, this is just what morph does, if you want something different you're looking for a different tool" in other words, this is a real suggestion, not snark or anything | 12:07:23 |
| srhb | I think that is likely the case, but post activation is low-hanging-fruit and provides the features that nixops has. | 12:07:26 |
| @grahamc:nixos.org | yeah | 12:07:31 |
| srhb | Which a lot of people really do expect. | 12:07:49 |
| @grahamc:nixos.org | not quite, actually, because nixops's secrets support also creates automatic systemd services you can depend on, which "start" when that specific secret is uploaded | 12:08:03 |
| srhb | Yes, but you could implement that yourself with "post" | 12:08:42 |
