8000 chore: add files cache for reading template tar archives from db by aslilac · Pull Request #17141 · coder/coder · GitHub
[go: up one dir, main page]

Skip to content

chore: add files cache for reading template tar archives from db #17141

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Apr 2, 2025

Conversation

aslilac
Copy link
Member
@aslilac aslilac commented Mar 27, 2025

Closes #17052

Requirements

  • Multiple template versions can share a single "file"

    • This is solved by using a map from file id to fs.FS interface pointers.
  • Files should be "ref counted" so that they're released when no one is using them.

    • This is solved by using a ref count, obviously :^)
  • You should be able to fetch multiple different files in parallel, but you should not fetch the same file multiple times in parallel.

    • This is solved by using a global sync.Mutex and a lazy.ValueWithError per file ID.

Implementation

  • Uses afero for turning the tar data from the database into a readonly io/fs.FS

  • Adds a lazy.ValueWithError as a counterpart to lazy.Value, but with the ability to fail

@aslilac aslilac force-pushed the lilac/files-cache branch from bad07d5 to 3c6b6ed Compare March 28, 2025 15:13
@aslilac aslilac requested a review from Emyrk March 28, 2025 17:48
@aslilac aslilac marked this pull request as ready for review March 28, 2025 17:50
@aslilac aslilac force-pushed the lilac/files-cache branch from 5cf9b25 to 125ef95 Compare March 28, 2025 23:01
Copy link
Member
@Emyrk Emyrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LG!
Maybe we should add some metric on the entry for when it was created. At some point some metrics like how long an entry exists would be useful.

We might even enforce some TTL or something 🤷

@aslilac
Copy link
Member Author
aslilac commented Apr 1, 2025

We might even enforce some TTL or something

what would it look like if the entry got evicted while someone was holding it? the gc wouldn't actually free it, but then if someone requests it again we'd end up with a separate copy of everything because the cache would no longer see it. I kinda feel like an expiration time would only mask bugs.

@aslilac aslilac requested a review from Emyrk April 1, 2025 22:07
@Emyrk
Copy link
Member
Emyrk commented Apr 2, 2025

We might even enforce some TTL or something

what would it look like if the entry got evicted while someone was holding it? the gc wouldn't actually free it, but then if someone requests it again we'd end up with a separate copy of everything because the cache would no longer see it. I kinda feel like an expiration time would only mask bugs.

You are right. Can we add an issue to throw some prometheus metrics around this then? So if something does happen, we have somewhere to look.

Copy link
Member
@Emyrk Emyrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 LGTM, left a few nits

Some things to follow up:

  • Add an issue for adding prometheus metrics to this cache
  • Potentially revisit the API when we get to usage. If we can guarantee Release is called, that would be ideal 🙏

@aslilac aslilac merged commit ac7ea08 into main Apr 2, 2025
29 checks passed
@aslilac aslilac deleted the lilac/files-cache branch April 2, 2025 22:42
@github-actions github-actions bot locked and limited conversation to collaborators Apr 2, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add filesystem cache for dynamic parameters loading tf files
2 participants
0