phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
q3k has quit [Ping timeout: 260 seconds]
q3k has joined #nixos-dev
drakonis has joined #nixos-dev
<flokli>
domenkozar[m]: niksnut: gchristensen: I'd like to do some more testing around https://github.com/NixOS/nixpkgs/pull/66856. As this is a pretty hefty rebuild, any chance to get a jobset scheduled with this?
<clever>
with this, i can nix-env -iA foo.hello to use a clone of nixpkgs, or nix-env -iA cardano.something to install something from the default.nix within cardano-develop
<clever>
it needs to return either a set, or a function you can auto-call with {} to get a set
justanotheruser has joined #nixos-dev
kalbasit has joined #nixos-dev
ris has quit [Remote host closed the connection]
ris has joined #nixos-dev
ixxie has quit [Quit: Lost terminal]
__monty__ has joined #nixos-dev
<gchristensen>
I wonder if preferLocalBuild should add an implicit feature to the derivation like ("local"), and then if someone wants to allow only local-only builds locally, they could add that feature to their local machine
<gchristensen>
because right now you can't prevent local builds even with max-jobs=0. the only method I've found is setting the machine's `system` to a bogus type
<LnL>
hydra or the remote build stuff also has some weird workarounds for local builds IIRC
<gchristensen>
yeah I think you're right, the builtins:local thing, right?
<LnL>
oh yeah, might be what I'm thinking of
<matthewbauer>
I would think `preferLocalBuild` shouldn't be a hard requirement. I didn't know that it made you do it locally?
<matthewbauer>
I was actually wondering yesterday if there was some general heuristic for whether to do a local build.
<matthewbauer>
It ends up being whether the time to upload + download something is greater than the speed up from doing a remote build. If we knew the output size of a derivation ahead of time, we could turn it on any time the input size is some constant factor of output size. But output size isn't easy to know ahead of time.
<gchristensen>
yea
<gchristensen>
which is the purpose of preferLocalBuild -- to tell nix, instead of make a heuristic
<matthewbauer>
yeah, but i think there's probably a few cases where you might not realize local is faster. things like compression and building disk images are almost always best to do preferLocalBuild. but i think when you have lots of small derivations, you can occasionally get speed up as well from preferLocalBuild
<matthewbauer>
probably because of latency
<matthewbauer>
and so if the remote builder is on your lan, you might actually want compression and disk images to use remote since there's less cost
<gchristensen>
we're bumping in to this same issue again and again, which is our ability to express what we want isn't sufficiently flexible. for example, I *do* want to distribute building disk images remotely. I also do want to ask remote builders to substitute on their own. my use case isn't yours, though
<gchristensen>
the protocol / config isn't so flexible, though, and so the list of what settings should be sent to which remote builder are poorly defined, and so some minimal set has been picked
<matthewbauer>
hmmm... yeah. i do think there's a universal use case here though - everyone just wants the fastest strategy. there's some concerns with security & how much your builders trust you though.
<gchristensen>
for sure
<gchristensen>
but we (the daemon) can't really know
rajivr has quit [Quit: Connection closed for inactivity]
<colemickens>
That looks great at first glance. Better than what I'd been imagining rigging up for KV integration and using stuff that's already built/tested.
<infinisil>
Mic92: Neat
<Mic92>
I already got access to GCP credits so I can integrate GCP KMS. If someone would sponsor me AWS KMS or Azure Key vault I would implement it as well.
<infinisil>
Mic92: So if I understood this correctly: The idea is to check each deploy hosts public key into the git repo. sops then generates the secrets.yaml file with all secrets encrypted with all the public keys separately. The file gets transferred to each host, which can then decrypt the secrets
<Mic92>
infinisil: yes. The sops file can be transferred manually or added to the nix store. One could also have shared private keys, which may scale better with a large number of homogen servers.
<Mic92>
I will finish the documentation over the next days and add some more examples
<infinisil>
Mic92: I guess there isn't a distinction of which machine can access which secrets?
ixxie has joined #nixos-dev
<infinisil>
Oh I guess you can have a separate secrets.yaml file for each host
<Mic92>
yes
<colemickens>
For the cloud providers, I assume you'll integrate on the vm/identity side too right?
<Mic92>
This is what services like GCP KMS is for
<Mic92>
It's already implemented in sops itself. I just need to add the right config options/environment variables.
<colemickens>
I can get you access to an Azure subscription, but I'm also down to take a crack at it right now. DM me if you want me to make you admin on a subscription for a while.
<Mic92>
The smallest VM for a few hours is probably all I need.
<infinisil>
Hm, I guess sops-nix could even be added to nixpkgs
<Mic92>
I want to collect some users before that though to see if I got the interface right.
<Mic92>
Most of my time spent until now was on fixing the horrible GPG UX.
<colemickens>
Mic92: You'll want access to the sub so you can touch KV/RBAC, etc. I don't mind, is your usual commit email your Microsoft account email?
<colemickens>
I can leave a prebooted VM too
<Mic92>
colemickens: no. its joerg.msn@higgsboson.tk but I changed it to joerg.msn@thalheim.io (it will take ages though before they will process this address change).
<Mic92>
I suppose I need to access this RBAC stuff.
<cole-h>
Mic92: Does sops only work on .yaml or .json files? e.g. no encrypted extensionless files?
<colemickens>
Mic92: You should be able to see the subscription in the portal/cli (there's a shell.nix with the CLI in nixos/maintainers/scripts/azure-new) and you should be able to `ssh cole@52.156.129.54` with your github key.
<Mic92>
colemickens: works.
<Mic92>
colemickens: I think I will have a look into this again next weekend. Should I turn of the VM?
<colemickens>
Mic92: sure, it's no sweat if you forget. Worst case scenario the quota runs out and resets on the 23rd.
<Mic92>
colemickens: I am not seeing the subscription yet in the azure portal.
<colemickens>
I don't know if you have to accept an invitation to the Active Directory instance. It said it sent invites to you.
<Mic92>
ok
<Mic92>
I check my emails
<colemickens>
And then after accepting, you might need to switch the directory you're on, in the portal, between the console and bell icons in the top right, is a Directory/Subscription filter.
<Mic92>
works now
<Mic92>
colemickens: I suppose when it's stopped it only costs for the disk space?
<colemickens>
Yes. And to be specific, in Azure you have to make sure to Stop via Portal/CLI/API. Shutting down the instance doesn't deprovision it.
<Mic92>
Done that
<cole-h>
colemickens++
<{^_^}>
colemickens's karma got increased to 31
<Mic92>
colemickens: is this some free tier credits you got there?
<colemickens>
I mean, Mic92++ really. I did the easy part.
<{^_^}>
Mic92's karma got increased to 30
<cole-h>
As easy as it is, it still needed doing :)