74 lines
2.7 KiB
Markdown
74 lines
2.7 KiB
Markdown
---
|
|
title: "Resolution 013: Budget 007: Operator sync - 2024-01-??"
|
|
---
|
|
|
|
!!! note
|
|
|
|
This resolution has been amended! The main change was to remove automatic
|
|
git synchronisation; please see [the file
|
|
history](https://git.coopcloud.tech/coop-cloud/docs.coopcloud.tech/commits/branch/main/docs/federation/resolutions/in-progress/013.md) for a full run-down.
|
|
|
|
- Deadline: 2024-01-XX
|
|
- Size: Large
|
|
|
|
### Summary
|
|
|
|
As highlighted in several tickets (e.g. [`#434`](https://git.coopcloud.tech/coop-cloud/organising/issues/434), [`#467`](https://git.coopcloud.tech/coop-cloud/organising/issues/467)), several operators working together on the same server routinely run into deployment instability. This is due to the fact that we do not store the deployment version of the apps.
|
|
|
|
With this proposal, we would like to address the synchronisation of app deployment versions. This is being called "Operator sync". What follows is the design proposal which has already received feedback from operators on [this pad](https://pad.riseup.net/p/IebZQkpe3OOpYyVT8f1j-keep).
|
|
|
|
### Details (Budget 007)
|
|
|
|
We add support a config file (`$ABRA_DIR/config.yml`) which has these defaults:
|
|
|
|
We also add a `abra config` command which has the following shape:
|
|
|
|
```
|
|
🌻 ./abra config -h
|
|
NAME:
|
|
abra config - Manage system-wide Abra configuration
|
|
|
|
USAGE:
|
|
abra config command [command options]
|
|
|
|
COMMANDS:
|
|
generate, g Generate default configuration
|
|
|
|
OPTIONS:
|
|
--help, -h show help
|
|
```
|
|
|
|
If there is no `$ABRA_DIR/config.yml` or `sync: false`, nothing changes. When `sync: true`, *only* the `abra app deploy / upgrade / rollback` commands have new behaviour.
|
|
|
|
There is also a new command `abra app sync <domain>` which triggers a synchronisation.
|
|
|
|
When `abra app deploy/upgrade/rollback/sync` is run, here's what we do:
|
|
|
|
* Read the `OPERATOR_SYNC_VERSION` env var as the version to deploy / upgrade from / rollback from
|
|
* upgrade: if deployed version does not match `OPERATOR_SYNC_VERSION`, warn before overview
|
|
* rollback: same as above!
|
|
|
|
* Run the deployment
|
|
* if successful, record a new `OPERATOR_SYNC_VERSION`
|
|
* if unsuccessful, do not record a `OPERATOR_SYNC_VERSION` and ask operator to resolve
|
|
|
|
If `--chaos` is passed, we use the short commit hash instead of the version label.
|
|
|
|
Here's an example of the `OPERATOR_SYNC_VERSION` env var:
|
|
|
|
```
|
|
# in ~/.abra/servers/example.com/matrix.example.com.env
|
|
TYPE=matrix-synapse
|
|
OPERATOR_SYNC_VERSION=4.0.0+v1.93.0 # managed by Abra
|
|
```
|
|
|
|
Operator documentation will also be provided.
|
|
|
|
**Budget amount**: 200 EUR (10 hrs * 20 EUR/hr)
|
|
|
|
**Who will implement this**: (someone?)
|
|
|
|
**When will the money be spent**: Before mid-February 2024
|
|
|
|
**What is the money for**: Implementing the first steps of operator sync.
|