Feature request: declarative cache configuration.

[henningphan]

Hello,
Would be nice if the attic server config would have options for caches and their settings so its not a manual process to create them.
Example

declarative = (hard|soft|true|false)
[cache.my_cache]
public = true
retention = 2 days

[cache.my_other_cache]
public = false
retention = 3 days

The global declarative option dictates if caches without a corresponding config section should be deleted.

[vonjackets]

Scripting the initialization, authentication, and cache creation steps feels like an intuitive workflow at the moment, despite the imperative nature of it. This feature could introduce security concerns. If a bad actor gains access to the server, declares a poisonous caches without clients knowing it could be a big problem. Figuring out a logging solution to create an audit trail to ensure we know who made the caches and when may be a big piece of this.

[LoganBarnett]

How would a declarative configuration be any different (or worse) in security posture than a home rolled, scripted solution?

Edit: Typo.

[henningphan]

@vonjackets
I would say scripting has bigger flaws, if we have configuration as code I can clearly see if the attic config has drifted by just comparing to my casc. But its not easy to see if it has drifted if we have to script it, because scripting usually just activates settings we want, but doesnt remove already preactivated configurations

Also if its only deployed through a cicd pipeline I can also see who made the change in git so we get some sort of audit trail by git logs, extra powerful if we can just check for intruders by checking if we drift.

[vonjackets]

But its not easy to see if it has drifted if we have to script it, because scripting usually just activates settings we want, but doesnt remove already preactivated configurations
I agree here. A declarative setup would eliminate any need/desire for that part of the setup. Though I'm still new to this project (and nix) myself. Do you have a solution in mind? @henningphan

Also if its only deployed through a cicd pipeline I can also see who made the change in git so we get some sort of audit trail by git logs, extra powerful if we can just check for intruders by checking if we drift.
Pairing that with logs that detail how subsequent caches got created via the client would enable a lot of fact-finding! Perhaps that could be another quality of life improvement

[henningphan]

@vonjackets I outlined a solution when I opened this feature request, I would guess the database holds the state and the config would check against the database what needs to change. I dont have any code as Im not familiar with rust.