Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Q5: git annex for machine state #68

Closed
blaggacao opened this issue Jan 5, 2021 · 3 comments
Closed

Q5: git annex for machine state #68

blaggacao opened this issue Jan 5, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@blaggacao
Copy link
Contributor

blaggacao commented Jan 5, 2021

"Q5 / Future Thinks + No Budget"-office here again. 😉

I stumbled over https://git-annex.branchable.com/ and it looks like a suitable idea on how to manage user state.

cc/ @cole-h since his readme prominently exposes the challenge.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@blaggacao
Copy link
Contributor Author

blaggacao commented Jan 11, 2021

Though gitlab decided to drop support a while ago in favor of git lfs, details: https://gitlab.com/gitlab-org/gitlab/-/issues/1648

On the other hand git annex supports "special remotes", including git LFS, which makes git annex a super versatile tool for syncing state to whatever service is preferred.

@nrdxp nrdxp added the enhancement New feature or request label Feb 17, 2021
@jorsn
Copy link

jorsn commented Feb 24, 2021

@blaggacao What do you mean by “user state” exactly? Only immutable state provided by “the system”?

Things to consider:

  1. You only need git-annex for large files, so not password files etc.
  2. It ties you completely to git, which hinders progress (look e.g. at pijul)
  3. Git-annex only has gains over plain (possibly encrypted) git-lfs if you want to have a partial state in some repos and configure the spread of the data over the repositories.
  4. At least you'd have to handle unlocking+locking/commiting of files as by default everything is immutable and referenced by symlinks.
  5. For mutable files/non-symlink mode git-annex uses gits smudge/clean filters which the whole file is in principle piped through (though git-annex uses some tricks there). This is inefficient if you don't really need these filters.
  6. Yet another really complex component of this system. Nix + git-annex + dhall + systemd for a basic system looks a bit complex to be suitable for a “community consensus on how to manage a NixOS system”, which should also be understandable by beginners (Simplify devos #137).

For mutable state: What about dysnomia?

@blaggacao
Copy link
Contributor Author

blaggacao commented Feb 24, 2021

Those are very thoughtful points, thank you!

I'm especially intrigued by pijul which seems to be a modern alternative to sqlite's fossil. I will keep an eye on it.

What do you mean by “user state” exactly? Only immutable state provided by “the system”?

Not sure.

In principle, git lfs does the job of putting blobs under the same workflow as system state, too. I have no understanding if pijul/fossil have a similar feature.

A vcs based workflow might serve two goals, in this context:

  • snapshotting
  • syncing (between hosts)

Dysnomia sounds interestingly convoluted which might or might not constitute a quality attribute (which I'm far from able to judge). I hope the docs get more accesible as the project evolves.

Maybe we actually need syncing and snapshotting only as a useful afterthought for some classes of state?

(hypothetocally)

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants