| 24 Oct 2021 |
 @teutat3s:pub.solar | how do I convince it to re-evaluate and put a new hashed entry of the missing file into the store? | 00:16:14 |
| @teutat3s:pub.solar | this is a fix I've now applied, too. it still tries to access the old gc'ed path though
https://github.com/divnix/devos/commit/8a590c9fefa893dd738bc3161052ac9ea5c72c80 | 00:17:48 |
 ultranix | for devops what's the workflow for public repositories, say on github. do you make a bot that rebuilds nixos machines with the proper keys using agenix, when a commit is added? | 05:22:59 |
| ultranix | i was thinking of doing that but never have before, so far i have only built the machines locally and deployed | 05:23:24 |
 b12f | basic PR, only removing git-crypt for now https://github.com/divnix/devos/pull/395 | 17:38:51 |
 @kraftnix:matrix.org | In reply to @teutat3s:pub.solar
Did anybody already try using agenix for grub / initrd keyfiles? Upon rebuild switch the step updating GRUB 2 menu comes before agenix decryption step and thus fails because the secret is not yet copied in clear text to /run/secrets yes, i have been managing initrd ssh keys with devos/agenix for a few months now without issue.
it does have a few pain points but you can work around them for now without any upstream changes.
you can currently point agenix to decrypt secrets to a location other than /run/secrets, if you set it to somewhere in /etc, then you can access those secrets during a rebuild, which means rebuild can use those agenix secrets for building the bootloader.
however because the bootloader is built before the agenix secrets are decrypted you have an issue where the agenix initrd secrets are always lagging one generation behind the current build, so you need to rebuild/deploy twice to have the bootloader rebuilt with the correct keys, which is not great ergonomics but it works, and since i almost never change the initrd ssh keys, it works fine.
the other small issue is the rebuild will not work unless there are already keys present when you first use agenix for initrd ssh keys, however this can be worked around by either generating fake keys (that will be replaced instantly by agenix on rebuild), just to get you past the first rebuild. | 19:13:49 |
| @kraftnix:matrix.org | admittedly it is a bit of a hack that goes around/against properly reproducible builds/deployments | 19:14:51 |
| 25 Oct 2021 |
|  andrew joined the room. | 00:13:48 |
 genadij.udarov | According to [1], devos should replace nixops? Or is it still possible use them in together? To avoid XY problem: I'm trying to use nix to provision throwaway environments in GCE. I'd like to avoid terraform. My plan here would be to use NixOPS to create GCE resources (VPCs, VMs, whatnot), and then use devos to provision them via deploy-rs. Would this be viable approach? Are there any alternatives?
[1] https://devos.divnix.com/integrations/deploy.html
| 17:24:59 |
| genadij.udarov | * According to [1], devos should replace nixops? Or is it still possible use them in together? To avoid XY problem: I'm trying to use nix to provision throwaway environments in GCE. I'd like to avoid terraform. My plan here would be to use NixOPS to create GCE resources (VPCs, VMs, whatnot), and then use devos to provision them via deploy-rs. Would this be viable approach? Are there any alternatives?
Edit: I'd like to point out that I'm a newbie when it comes to nix stuff.
[1] https://devos.divnix.com/integrations/deploy.html
| 17:25:34 |
 David Arnold (blaggacao) | genadij.udarov From my standpoint I'd try to use terraform. You can write tf files in json, instead of hcl (hcl is a superset of json). | 17:28:21 |
| David Arnold (blaggacao) | You can write json in nix. | 17:28:35 |
| David Arnold (blaggacao) | nix eval --json .#my-gce-env | tf ... | 17:29:10 |
| genadij.udarov | I'd like to avoid the tfstate thingy... | 17:29:18 |
| David Arnold (blaggacao) | You swap tfstate for nixops state. | 17:29:42 |
| David Arnold (blaggacao) |
- most providers do only keep state for speed and can fully recover from a lost state through the remot APIs.
| 17:30:16 |
| David Arnold (blaggacao) | * + most providers do only keep state for speed and can fully recover from a lost state through the remote APIs. | 17:31:04 |
| genadij.udarov | Ah, makes sense. It would be great if I could use cloud provider as a source of truth using labels/tags/whatnot. I guess the tech is not here yet. :-D
Speaking of nix eval, should I write the .#my-gce-env output (that's the term in flake, right) myself, or are there some libs to do so? | 17:31:06 |
| genadij.udarov | In reply to @blaggacao:matrix.org
- most providers do only keep state for speed and can fully recover from a lost state through the remote APIs.
Interesting. Didn't know about that. | 17:31:39 |
| David Arnold (blaggacao) | You can use terranix, but I'd recommend doing copy-hcl / pasta-json-nix directly from the upstream docs. | 17:31:59 |
| David Arnold (blaggacao) | This gives you a significantly increased body of documentation. | 17:32:20 |
| genadij.udarov | upstream docs being tf docs, right? | 17:32:39 |
| David Arnold (blaggacao) | The obly trick is: "copy-hcl / pasta-nix-json` | 17:32:43 |
| David Arnold (blaggacao) | * The only trick is: "copy-hcl / pasta-nix-json` | 17:32:50 |
| David Arnold (blaggacao) | That transformation is really obvious after ~1/2 hour of playing. | 17:33:22 |
| David Arnold (blaggacao) | * That transformation is really _obvious_ after ~1/2 hour of playing. | 17:33:37 |
| genadij.udarov | Thanks! | 17:37:21 |
| David Arnold (blaggacao) | You should be able to use cloud providers as a source of truth with terraform data resources. | 17:38:33 |
| David Arnold (blaggacao) | You need to make a trade-off decision, though how much exogenous information you want to accept / can't avoid in your gitops workflow. | 17:39:18 |
| David Arnold (blaggacao) | I'd say: exoginous is ok if you can't avoid it.
Exogenous is ok for those "efimeral" envs that you spoke of. | 17:40:09 |
