WIP: add attic cache #397
No reviewers
Labels
No labels
0 points
0.5 points
1 point
13 points
2 points
21 points
3 points
34 points
5 points
55 points
8 points
api service
blocked
component: fediversity panel
component: nixops4
documentation
estimation high: >3d
estimation low: <2h
estimation mid: <8h
infinite points
productisation
project-management
question
role: application developer
role: application operator
role: hosting provider
role: maintainer
security
technical debt
testing
type unclear
type: bug
type: deliverable
type: key result
type: objective
type: task
type: user story
user experience
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Depends on
Reference: fediversity/fediversity#397
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "kiara/fediversity:attic"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
closes #92.
follow-up: https://git.fediversity.eu/Fediversity/Fediversity/compare/main...kiara:access-cache-from-runner
@ -108,0 +110,4 @@atticS3KeyConfig ={ pkgs, ... }:{# REVIEW: how were these generated above? how do i add one?/cc @Niols hoping to better understand this 😅
4fff023115to8d5d18cf62Why would attic be operator facing? I’d say it’d be part of the hosting provider’s Fediversity setup. Instead of plugging new noise into PoC code that needs cleanup before anything else, let’s focus on the application data model.
I understand we need that for our CI and #92 is still valid, but the code for that woule live somewhere else entirely.
i think caching is what i can do for #362 (given my lack of access so far to the runner node), which we prioritized above #103.
the initial reason i starting exploring having this in
operatoroverdevwas that was where we'd done used applications in garage before, while we've had better testing for operator stuff as well - tho the reason i allowed myself to explore that direction has been #370.Yes I know, we half jokingly discussed how meta it would be if we deployed our dev infra through the operator workflow. But it would complicate the bootstrapping of our business logic because we first need the simple things to work, and arguably a CI with cache is at least medium fancy. We don’t need cool deployment to improve CI robustness and performance. Just hack it in somehow for now, as long as it’s under version control and reasonably nixed. But we can target our dev infra as a use case once we have a better grasp on the mechanics of the application.
@fricklerhandwerk i feel being able to iterate on this using our test infrastructure is helping me get this to a state where it may get our CI more usable. if containers fix our problems first tho, that's great.
bc9ce3261etof6c4485ade@ -108,0 +113,4 @@# REVIEW: how were these generated above? how do i add one?s3AccessKeyFile = pkgs.writeText "s3AccessKey" "GKaaaaaaaaaaaaaaaaaaaaaaaa";s3SecretKeyFile = pkgs.writeText "s3SecretKey" "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";};I don't actually know. I suppose they have been generated using Garage itself?
CI correctly reproduced my local error, but what is this error
Broken pipeanyway 😿issues in the log:
failed to download acl
OOM
IIUC, the OOM can be fixed by changing:
virtualisation = {## NOTE: The deployer machines needs more RAM and default than the## default. These values have been trimmed down to the gigabyte.## Memory use is expected to be dominated by the NixOS evaluation,## which happens on the deployer.memorySize = 4 * 1024;diskSize = 4 * 1024;cores = 2;};For the “failed to download”, that's nastier, we're back to trying to guess packages that need to be added to the derivations. A first step would be to enable the new Attic Fediversity module in
check-deployment-cliandcheck-deployment-paneland see if that fixes it. See:system.extraDependenciesFromModule = {imports = [ ../../../services/fediversity ];fediversity = {domain = "fediversity.net"; # would write `dummy` but that would not typegarage.enable = true;mastodon = {enable = true;s3AccessKeyFile = dummyFile;s3SecretKeyFile = dummyFile;};peertube = {enable = true;secretsFile = dummyFile;s3AccessKeyFile = dummyFile;s3SecretKeyFile = dummyFile;};pixelfed = {enable = true;s3AccessKeyFile = dummyFile;s3SecretKeyFile = dummyFile;};temp.cores = 1;temp.initialUser = {username = "dummy";displayName = "dummy";email = "dummy";passwordFile = dummyFile;};};};};the OOM i solved.
the `acl` download error persists despite a seemingly relevant patch.
the log seems to continue for a while tho, making me unsure if the ACL thing is fatal, tho i don't see clear fatal errors in the log to begin with, hm.
i may have use for a second opinion here.
23fdba786dtod53dff003e@kiara wrote in Fediversity/Fediversity#397 (comment):
yay \o
This is not what you should do. Probably, your Attic module pulls much more than just
pkgs.acl. Try enabling it inextraDependenciesFromModule, as suggested in Fediversity/Fediversity#397 (comment).d53dff003etof575e8cdeaf575e8cdeatobd869f2763my attempt following that advice, unfortunately to no avail
My two last commits seem to fix it locally. Let's see what the CI says.
The Attic service got its own switch. I suppose we mean for it to be one of the Fediversity services that we provide? This is probably just another formulation of @fricklerhandwerk's question.
I see you add code to click on the
attic.enablecheckbox, but you haven't added the checkbox (or anything) to the panel if I'm not mistaken.You haven't mentioned the changes to
sources.jsonbut they are not trivial. How stable are those dependencies? What do your forks provide that the upstream does not?Also, in general, please stop packing together in a WIP PR changes that are unrelated to each other. This makes the diff harder to read, errors harder to debug, and it increases the chances that PR never lands, in which case we would lose some changes that are in fact perfectly reasonable.
For instance, this PR contains:
Random flipping of booleans in
configuration.sample.json(568cafb2f9). If you believe this is better that way, just open a three lines PR that does this and it will get merged instantly. Or.... in this case, you would see that CI rejects it because it breaks the tests, and you wouldn't have (and I wouldn't have) to debug a 500 lines PR.A commit called “unrelated improvements” (
eb63c9072a). If you recognised that this was unrelated, why put it in this PR? Why add 15 lines to an already big diff?Changes to
infra/common(15f1909de3). Just put them in their own mini PR and they will be merged within a day. Now, they just make it harder to read the actual change that your PR is hoping to implement.nice - thank you @Niols!
@Niols wrote in Fediversity/Fediversity#397 (comment):
thanks! how did you think of this package, despite it not getting mentioned? was this some reverse dependencies trick?
apologies, agree, I should have cleaned better before requesting feedback.
to answer a specific question there tho:
I believed it might have been needed to test this, and had been in the process of validating that, tho facing errors I hadn't gotten far enough to find the answer.
is the GUI not just generated from
deployment/options.nix?CI looks good!
i just cared about getting this usable to us, and being able to use the garage and testing code i considered to help get closer to that - tho for our purposes, technically it might service us even if deployed 'as an operator' for now. i'd agree tho that isn't preferable, #370 experiments aside.
right, i hadn't gotten the PR out of a wip experiment stage yet
varsis a library clan distilled from their mono-repo after a period of internal use. they intend to upstream, and are gathering feedback on that.my fork was an attempt to add templating to allow interpolating sensitive values in string templates, see https://github.com/Lassulus/vars/issues/1.
nix-templatingis the follow-up effort between lassulus and myself to loosen templating coupling from vars, tho i hadn't gotten it to work here so far - then forgot to clean it up while testing my fork of vars instead. i considered this an ugly compromise tho, and wanted to find a way to use the upstream versions of both.for what it's worth, my fork of
nix-templatingconsists of a simple outstanding PR to facilitate use without using flakes.on stability, i would consider that library an (unmaintained) proof-of-concept.
let me see if i can use your progress to deploy this now...
4fd361ebb8toa0fb9920ba@kiara wrote in Fediversity/Fediversity#397 (comment):
The download error was about
attrandacl, I believe, but then there is a stream of “A dependency of failed” errors, and they get higher and higher level. At the end of it was ShellCheck, which makes sense, because ShellCheck would be in the build closure of many things, but not in the runtime closure!It is probably my fault for looking at a WIP PR. Sorry about that.
Fair enough!
Oh yes, I suppose it is. Absolute magic, I love it!
I think that's perfectly reasonable and deserves to be merged as-is. We can always clean those things up later on.
Sounds good, thanks for giving details. So we are hoping that the
nix-templatingPR gets merged and that we can go back to following upstream? Would you also qualify upstream of an (unmaintained) proof-of-concept? Either way, for our current work, that sounds reasonable!In general, the current state of the PR looks good. What is there you want to do before merging this?
actually try it out 😅, on the road to that i'd now bumped into #431 so far.
ideally yes
honestly tho, i've seemed no less active on that repo myself, with so far no further contributors.
as such, a third option could be to just pull the repo into our org, particularly given the code is limited enough such that expected maintenance seems within reason.
nah, i'd been asking for your advice here on multiple occasions already 😅
a0fb9920bato1e51393fb8deployment seems working.
server side:
atticindeployment/configuration.sample.jsonnixops4 apply testssh test12.abundos.eu:client side:
(note i get complaints about not being a trusted user unless running these as root, tho otherwise this works.)
nixops4 apply testerror:proxmox-qemu-vm.nix was imported into nixops4Resource instead of nixosnixops4 deploy test: You must definesecurity.acme....nixops4 deploy test: You must definesecurity.acme....1e51393fb8to0da4c763360da4c76336toeb26d7c607eb26d7c607to6d4dc82430e85eac9733to5282bb1b7e4a253dbf11to5bac5bda1bprogress as per CI:
Error: No servers are available- maybe that also needs to use thelogin/usecommands still (or directly configure the~/.config/attic/config.tomlthat the former sets up).fyi attic can be unlisted by clearing the
substituters/trusted-public-keys/netrc-fileentries it adds to~/.config/nix/nix.conf, as well as cleaning up its added~/.config/nix/netrc.5bac5bda1bto9b5f5fedfdcab58453e7to7b5309560ccf1bde166fto8c65cd5ffafbd0541f9ftoe790a4450f6f84682e91tofbe1eb034509e68bc9e3to24fd6516bef76f0b9db6to15768b01d315768b01d3to2f46224f4ad9e20da63ftof195a358caebc1534cfbto94b8072b2394b8072b23to784a65930adespite using
trusted-userson my local setup, attic's generated user config does still give me warnings on nix builds:warning: Ignoring the client-specified setting '...', because it is a restricted setting and you are not a trusted user
edit: i think i solved that by ditching some local nix cache (?)
current CI failure is because the cache isn't currently deployed
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.