forked from toolshed/docs.coopcloud.tech
docs: shuffle resolutions
This commit is contained in:
@ -1,75 +0,0 @@
|
||||
---
|
||||
title: "Resolution 013"
|
||||
---
|
||||
|
||||
!!! 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.
|
||||
|
||||
- Budget 007: Operator sync
|
||||
- Date: 2024-01-??
|
||||
- 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.
|
||||
@ -1,57 +0,0 @@
|
||||
---
|
||||
title: "Resolution 021"
|
||||
---
|
||||
|
||||
- Topic: Budget 011: Migrate to Cobra
|
||||
- Date: 22-07-2024
|
||||
- Deadline: 31-07-2024
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
Migrate away from our current command-line dependency so `abra` usage is more predictable. The goal is to maintain feature parity with no breaking changes. The main advantage that we will get is robust and flexible handling of flags/arguments which don't depend on forcing a specific order (see [`#581`](https://git.coopcloud.tech/coop-cloud/organising/issues/581)). There are other bonuses such as built-in support for auto-completion, better handling of example usage, improved support for global flags (`--debug`) and manpage support.
|
||||
|
||||
### Details (Budget 011)
|
||||
|
||||
#### The problem
|
||||
|
||||
The current help output of `abra app deploy` is as follows:
|
||||
|
||||
`abra app deploy [command options] <domain> [<version>]`
|
||||
|
||||
However, it is possible to do both of the following:
|
||||
|
||||
```
|
||||
abra app deploy --chaos example.org # "before" style
|
||||
abra app deploy example.org --chaos # "after" style
|
||||
```
|
||||
|
||||
However, `abra app cmd` is broken if you try to use the "after" style:
|
||||
|
||||
```
|
||||
abra app cmd <domain> <function> --local -- <args>
|
||||
```
|
||||
|
||||
This results in `<recipe> doesn't have a --local function` which is a bug in the `abra` code. It tries to read the position of the arguments but `--local` is included as an argument. The bug in `abra` is due to a bug in `urfave/cli` - "after" style options appear as arguments 😱
|
||||
|
||||
The only way to use `abra app cmd` right now is using the "before" style:
|
||||
|
||||
```
|
||||
abra app cmd --local <domain> <function> -- <args>
|
||||
```
|
||||
|
||||
This means that some commands allow both "after" and "before" style and some only allow "before" style. This is a source of confusion, raised issues and frustration.
|
||||
|
||||
#### The solution
|
||||
|
||||
[Several](https://git.coopcloud.tech/coop-cloud/abra/pulls/404) [attempts](https://git.coopcloud.tech/coop-cloud/abra/pulls/435) have been made to upgrade `urfave/cli` to fix this behaviour. However, as it turns out, it is **highly unlikely** that they will fix this upstream: [`urfave/cli#1950`](https://github.com/urfave/cli/issues/1950) [`urfave/cli#1928`](https://github.com/urfave/cli/pull/1928) (and even this proposal does not really include the desired robust flexible handling we need).
|
||||
|
||||
`@decentral1se` has done a spike to confirm that [`cobra`](https://cobra.dev) handles flexible handling of arguments/flags. Those reading this proposal and wishing to try it out for themselves can take [Hugo](https://gohugo.io/) for a spin (it uses `cobra` as the underlying command-line library).
|
||||
|
||||
This tool is well maintained and used by several large projects such as Hugo and Kubernetes. The library matches all functionality we require.
|
||||
|
||||
#### Budget
|
||||
|
||||
`@decentral1se` can carry out this work.
|
||||
|
||||
Proposed budget of 15 hrs: `15 hrs * 20 = 300 EUR`
|
||||
27
docs/federation/resolutions/in-progress/022.md
Normal file
27
docs/federation/resolutions/in-progress/022.md
Normal file
@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Resolution 022"
|
||||
---
|
||||
|
||||
- Topic: Ammar joins the Co-op Cloud Federation
|
||||
- Date: 31-08-24
|
||||
- Deadline: 14-09-2024
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
> @ammaratef45:matrix.org
|
||||
|
||||
[@ammaratef45](https://git.coopcloud.tech/ammaratef45) is a software engineer and has:
|
||||
- Used Co-op Cloud for self-hosting libre apps.
|
||||
- Advocated for self hosting in his community in Seattle.
|
||||
- Participated in [https://matrix.to/#/#coopcloud-tech:autonomic.zone](our community) chats.
|
||||
- Some small contributions/fixes/bug reports for some Co-op Cloud stuff.
|
||||
- Published an abra recipe for photo prism.
|
||||
|
||||
### Details
|
||||
|
||||
I, Ammar Hussein, believe in the vision of Co-op Cloud and been invested in the
|
||||
success of similar initiatives. I would love the opportunity to fomrmally
|
||||
become a member of the federation and happy to contribute membership dues.
|
||||
|
||||
[Be Water](https://bewater.contact) is happy to vouch.
|
||||
Reference in New Issue
Block a user