Separate config and state directories #16

Closed
opened 3 years ago by fgaz · 4 comments
fgaz commented 3 years ago

Most services allow the user to keep configuration and data/state/cache separate (eg. /etc vs /var, ~/.config vs ~/.local/share/~/.cache).

This makes possible a bunch of stuff like:

  • different backup strategies for config and data
  • making the configuration read-only
  • easily cleaning the state while keeping the configuration

Some files used by fedigroups are fixed (config.json, groups.json..) and some are mutable (control.json, state.json..).
It'd be nice if fedigroups had a --data option in addition to --config, with which one could specify where the mutable state should go.

Most services allow the user to keep configuration and data/state/cache separate (eg. `/etc` vs `/var`, `~/.config` vs `~/.local/share`/`~/.cache`). This makes possible a bunch of stuff like: * different backup strategies for config and data * making the configuration read-only * easily cleaning the state while keeping the configuration Some files used by fedigroups are fixed (`config.json`, `groups.json`..) and some are mutable (`control.json`, `state.json`..). It'd be nice if fedigroups had a `--data` option in addition to `--config`, with which one could specify where the mutable state should go.
Owner

Have you seen the way it worked before? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo.

This is quite a big change and I dont personally want it, but if you add it, I'll probably accept the MR.

The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in. It shouldn't be too difficult to add.

Things to consider though:

  • the only really immutable files are groups.json and config.json in the group folders, except the latter actually is mutable in case of authing a new group or re-authing using -A. You can chmod it afterwards, of course.
  • control.json contains the member list, group tags etc. This file is mutated by the group actor when you tell it to using a slash command, when a user joins, etc. You don't want to lose it. It's separated from config.json so you can make config.json with the auth keys read-only.
  • state.json also should be backed up, unless you disable the notification catch-up feature, then it doesn't matter. This file is separated because it's overwritten very often.
Have you seen the way it worked *before*? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo. This is quite a big change and I dont personally want it, but if you add it, I'll probably accept the MR. The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in. It shouldn't be too difficult to add. Things to consider though: - the only really immutable files are `groups.json` and `config.json` in the group folders, except the latter actually is mutable in case of authing a new group or re-authing using `-A`. You can chmod it afterwards, of course. - `control.json` contains the member list, group tags etc. This file is mutated by the group actor when you tell it to using a slash command, when a user joins, etc. You don't want to lose it. It's separated from `config.json` so you can make `config.json` with the auth keys read-only. - `state.json` also should be backed up, unless you disable the notification catch-up feature, then it doesn't matter. This file is separated because it's overwritten very often.
Poster

Have you seen the way it worked before? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo.

I did not and yes, it sounds much better now

The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in.

what should happen if the user specifies --config but not --data? Should --data default to what is specified in --config or to the working directory?

you listed some config files and some data files. are there any cache files that can be removed without loss of data?

> Have you seen the way it worked before? Everything was in one big JSON file that was constantly overwritten. Kind of scary. The way its split now is much better imo. I did not and yes, it sounds much better now > The data directory would have to mirror the structure of the current groups directory, so by default nothing changes, but you can tell it to put data elsewhere if you opt in. what should happen if the user specifies `--config` but not `--data`? Should `--data` default to what is specified in `--config` or to the working directory? you listed some config files and some data files. are there any cache files that can be removed without loss of data?
Owner

I believe --config tells it where groups.json is, the groups and locales folders are then found relative to this file.

There's no cache files, that's why I'm kind of skeptical about this change.

I imagine it could work something like this:

/etc/fedigroups/

├── groups
│   ├── betty@piggo.space
│   │   └── config.json
│   └── chatterbox@botsin.space
│       ├── messages.json
│       └── config.json
├── locales
│   └── ru.json
└── groups.json

Notice how groups.json contains these:

    // name of the directory with groups
    "groups_dir": "groups",
    // name of the directory with locales
    "locales_dir": "locales",

So the data directory could be another entry, defaulting to "groups". But if you choose to split it, it will look like this:

/var/fedigroups/

├── betty@piggo.space
│   ├── control.json
│   └── state.json
└── chatterbox@botsin.space
    ├── control.json
    └── state.json
I believe `--config` tells it where `groups.json` is, the `groups` and `locales` folders are then found relative to this file. There's no cache files, that's why I'm kind of skeptical about this change. I imagine it could work something like this: `/etc/fedigroups/` ``` ├── groups │ ├── betty@piggo.space │ │ └── config.json │ └── chatterbox@botsin.space │ ├── messages.json │ └── config.json ├── locales │ └── ru.json └── groups.json ``` Notice how `groups.json` contains these: ``` // name of the directory with groups "groups_dir": "groups", // name of the directory with locales "locales_dir": "locales", ``` So the data directory could be another entry, defaulting to "groups". But if you choose to split it, it will look like this: `/var/fedigroups/` ``` ├── betty@piggo.space │ ├── control.json │ └── state.json └── chatterbox@botsin.space ├── control.json └── state.json ```
Poster

I see, thank you for the clarification. I missed the *_dir fields.

That actually makes this change useless as long as one considers config.json as data and if those fields can contain absolute paths.

I'll think about it.

I see, thank you for the clarification. I missed the *_dir fields. That actually makes this change useless as long as one considers config.json as data and if those fields can contain absolute paths. I'll think about it.
MightyPork closed this issue 3 years ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MightyPork/group-actor#16
Loading…
There is no content yet.