<gchristensen>
it looks like much of our aarch64 capacity was removed
<gchristensen>
some other customer at Packet wanted to pay more :)
drakonis_ has joined #nixos-dev
<adisbladis>
Pesky customers
drakonis has quit [Ping timeout: 245 seconds]
<gchristensen>
I just made a few changes to the persistent spot market requests to request nodes from more regions
<gchristensen>
RIP their provisioner because I accidentally created a request a way I didn't like, and I've provisioned and destroyed about 50 machines in the last 20min
<{^_^}>
oilshell/oil#509 (by adisbladis, 40 minutes ago, open): Add Nix based development environment
<gchristensen>
nice
drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
drakonis_ has joined #nixos-dev
eyJhb has quit [Quit: Clever message]
eyJhb has joined #nixos-dev
drakonis has quit [Ping timeout: 250 seconds]
drakonis_ has quit [Ping timeout: 250 seconds]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
__monty__ has quit [Quit: leaving]
drakonis_ has quit [Ping timeout: 246 seconds]
FRidh has quit [Quit: Konversation terminated!]
justanotheruser has quit [Ping timeout: 240 seconds]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
justanotheruser has joined #nixos-dev
ris has quit [Ping timeout: 258 seconds]
<aanderse>
so tmpfiles is better than mkdir as root
<aanderse>
but... tmpfiles is somewhat brittle
<tilpner>
aanderse: Brittle how?
<gchristensen>
it is very slow with large amounts of files to delete
<aanderse>
if we're going to continue down the path of every module allowing a dataDir option (most modules i have no idea why they want this to be honest) then we may want to reconsider how we provision these directories
<aanderse>
my "official" stance/opinion is we should utilize systemds StateDirectory, LogsDirectory, CacheDirectory, etc...
<aanderse>
gchristensen: depending how you use it, yes it can be
<aanderse>
using systemds directory structure solves so many problems, and so nicely
<gchristensen>
using those dirs sounds nice
<aanderse>
but those who insist they want to be able to choose dataDir for everything are quite vocal about it
<aanderse>
if i had the time i'd write an RFC to debate the topic
<aanderse>
well
<aanderse>
let me correct that
<aanderse>
energy
<aanderse>
sure i don't have the time
<aanderse>
but more importantly
<aanderse>
i don't have the energy -_-
<aanderse>
someone should start the discussion, and see it through, though
<tilpner>
aanderse: What is the practical difference between StateDirectory and dataDir?
<tilpner>
Oh
<aanderse>
tilpner: whatever the developer of the module wants?
<aanderse>
so
<tilpner>
StateDirectory doesn't allow a path, I forgot
<aanderse>
many modules have a dataDir set default "/var/lib/PROG_NAME"
<aanderse>
and hardly any users ever change that i imagine
<aanderse>
some do
<aanderse>
but i can't imagine that is the majority
<aanderse>
tilpner: brittle in that tmpfiles run on nixos-rebuild, or periodically
<aanderse>
StateDirectory runs on service startup
<aanderse>
tmpfiles has some nuanced rules that have bitten people who choose anything other than the default on more than one occasion
<tilpner>
Yeah, the string-typed interface is not great
ris has joined #nixos-dev
<infinisil>
There are some cases where it makes sense to have a dataDir option I think
<infinisil>
Well, actually not sure
<infinisil>
If dataDir means "This is where the program stores the data it manages itself" then maybe we really don't need such options
<tilpner>
One reason might be "I want service foo to run off my fast SSD, and service bar off my slow HDD mirror"
<tilpner>
That can be done via bind mounts, and if it's a big issue there could be a module for creating those
<infinisil>
Yeah was just thinking the same
<tilpner>
But I might be missing some edgecases here
<tilpner>
What if a service mounts into its stateDir? (recursive bind-mount?)
<tilpner>
What about DynamicUser?
<infinisil>
DynamicUser could be handled by a nixos bind module, by binding to /var/lib/private/<name>
<infinisil>
Actually no
<infinisil>
Just /var/lib/<name> too
<infinisil>
With a bind mount from ${dataDir} -> /var/lib/<name>, then a symlink to /var/lib/private/<name> set up by systemd
<infinisil>
So DynamicUser shouldn't be a problem
<infinisil>
tilpner: What do you mean by a service mounting into its state dir?
<tilpner>
infinisil: No usecase specifically, I just haven't considered cases where the service mounts things during runtime
<infinisil>
I see, I'd say we could just deal with it when it comes up (if ever)
<tilpner>
Specifically those where the mountpoint is around source or target of our workaround bindmount
<tilpner>
It would be better to argue with someone who insists on changing dataDir
<infinisil>
I'd probably implement the state bind module thing with a generic option `systemd.services.*.baseStateDirectory`
<infinisil>
Actually no, it should be something like `systemd.services.*.stateDirectory` with the full state directory path
<lopsided98>
I have deluge's data dir on a drive that is not mounted at boot, and the service is configured to not start until the mountpoint appears. tmpfiles breaks that because it tries to create the directory at boot
<infinisil>
Then it could do `if stateDirectory != "/var/lib/${serviceConfig.StateDirectory}" then <set up bind mounts>`
<infinisil>
lopsided98: Oh that's a good example
<infinisil>
lopsided98: Couldn't you use deluge's config to make it store torrent data somewhere else instead of using dataDir for that?
<lopsided98>
infinisil: The deluge module automatically feeds the "download_location" option to tmpfiles