Compare commits
1 Commits
main
...
resolution
| Author | SHA1 | Date |
|---|---|---|
 decentral1se
|
7de2547f10
|
|
|
@ -7,132 +7,57 @@ title: Cheat sheet
|
|||
!!! info
|
||||
not all flags are listed here.
|
||||
|
||||
!!! warning
|
||||
Definitely set up autocomplete or you'll be sad
|
||||
|
||||
### Abra Autocomplete
|
||||
`abra autocomplete bash/zsh/fizsh`
|
||||
|
||||
Definitely set up autocomplete or you'll be sad :sob: `abra` supports `bash`,
|
||||
`zsh`, and `fizsh` just run
|
||||
### create and deploy a new app:
|
||||
- `abra app new $RECIPE`
|
||||
flags: `-s/--server`, `-D/--domain`, `-S/--secrets`, `-p/--pass`
|
||||
- `abra app config $APPNAME`
|
||||
- `abra app secret generate $APPNAME -a`
|
||||
flags: `-p/--pass`, `-a/--all`
|
||||
- `abra app deploy $APPNAME`
|
||||
flags: `-f/--force`, `-C/--chaos`
|
||||
|
||||
```
|
||||
$ abra autocomplete bash
|
||||
```
|
||||
### undeploy and remove an app
|
||||
- back up any data you don't want to lose
|
||||
- `abra app undeploy $APPNAME`
|
||||
- `abra app rm --volumes $APPNAME`
|
||||
flags: `-f/--force`, `-V/--volumes`
|
||||
|
||||
### upgrade abra
|
||||
- `abra upgrade`
|
||||
flags: `--rc`
|
||||
|
||||
### Create & deploy an app
|
||||
|
||||
```
|
||||
$ abra app new $RECIPE`
|
||||
```
|
||||
|
||||
Optional flags: `-s/--server`, `-D/--domain`, `-S/--secrets`, `-p/--pass`
|
||||
|
||||
```
|
||||
$ abra app config $APPNAME
|
||||
$ abra app secret generate $APPNAME -a
|
||||
```
|
||||
|
||||
Optional flags: `-p/--pass`, `-a/--all`
|
||||
|
||||
```
|
||||
$ abra app deploy $APPNAME
|
||||
```
|
||||
|
||||
Optional flags: `-f/--force`, `-C/--chaos`
|
||||
|
||||
|
||||
### Restarting an app
|
||||
|
||||
To run `restart` you need to specify the `<service>` name with the default being `app`
|
||||
|
||||
```
|
||||
$ abra app restart <domain> app
|
||||
```
|
||||
|
||||
### Undeploy & remove an app
|
||||
|
||||
Back up any data you don't want to lose
|
||||
|
||||
```
|
||||
$ abra app undeploy $APPNAME
|
||||
$ abra app rm --volumes $APPNAME
|
||||
```
|
||||
|
||||
Optional flags: `-f/--force`, `-V/--volumes`
|
||||
|
||||
|
||||
### Upgrade abra
|
||||
|
||||
To upgrade `abra` itself, run the following:
|
||||
|
||||
```
|
||||
$ abra upgrade
|
||||
```
|
||||
|
||||
Option flags: `--rc`
|
||||
|
||||
|
||||
### Upgrade a recipe
|
||||
|
||||
```
|
||||
$ abra recipe upgrade $RECIPE`
|
||||
```
|
||||
|
||||
Option flags: `-x,y,z/--major,minor,patch`
|
||||
|
||||
```
|
||||
$ abra recipe sync $RECIPE
|
||||
```
|
||||
|
||||
Optional flags: `-x,y,z`
|
||||
|
||||
```
|
||||
$ abra recipe release $RECIPE [$VERSION]
|
||||
```
|
||||
|
||||
Optional flags: `-p/--publish`, `-r/--dry-run`, `-x,y,z`
|
||||
|
||||
|
||||
### Manually restoring app data
|
||||
|
||||
To manually restore app data or configurations, you can use the `cp` command as:
|
||||
|
||||
```
|
||||
$ abra app cp <domain> path/to/.app.conf app:/home/app/
|
||||
$ abra app cp <domain> path/to/data app:/home/app/
|
||||
```
|
||||
|
||||
*Note: the destination must be a directory and not a filename*
|
||||
|
||||
|
||||
### Make changes to a recipe
|
||||
|
||||
Edit the files in `~/.abra/recipe/$RECIPENAME`
|
||||
|
||||
Deploy the changed version to your test instance
|
||||
|
||||
Determine how serious your change is (semver.org for reference)
|
||||
|
||||
```
|
||||
$ abra recipe release $RECIPE [$VERSION]
|
||||
```
|
||||
### upgrade a recipe
|
||||
- `abra recipe upgrade $RECIPE`
|
||||
flags: `-x,y,z/--major,minor,patch`
|
||||
- `abra recipe sync $RECIPE`
|
||||
flags: `-x,y,z`
|
||||
- `abra recipe release $RECIPE [$VERSION]`
|
||||
flags: `-p/--publish`, `-r/--dry-run`, `-x,y,z`
|
||||
|
||||
### make a change to a recipe
|
||||
- edit the files in `~/.abra/recipe/$RECIPENAME`
|
||||
- deploy the changed version to your test instance
|
||||
- determine how serious your change is (semver.org for reference)
|
||||
- `abra recipe release $RECIPE [$VERSION]`
|
||||
|
||||
### Advanced Listing using `jq`
|
||||
|
||||
Several `abra` commands can output JSON formatted tables, and can thus be queried and filtered with the tool [jq](https://stedolan.github.io/jq/ "jq JSON Query tool"). We can also format these outputs with [tv](https://github.com/uzimaru0000/tv "tv Table Viewer") into a pretty table.
|
||||
|
||||
Currently, `abra recipe ls`, `abra server ls`, and `abra app ls` support the `-m` machine readable output flag which outputs JSON.
|
||||
|
||||
Currently, `abra recipe ls`, `abra server ls`, and `abra app ls` support the `-m` machine readable output flag which outputs JSON.
|
||||
|
||||
#### Filter recipes by "category"
|
||||
|
||||
```
|
||||
$ abra recipe ls -m | jq '[.[] | select(.category == "Utilities") ]' | tv
|
||||
```
|
||||
`abra recipe ls -m | jq '[.[] | select(.category == "Utilities") ]' | tv`
|
||||
|
||||
As you can see we, we're selecting all recipes where category is "Utilities".
|
||||
|
||||
|
||||
#### Filter apps by state `deployed`
|
||||
|
||||
!!! info
|
||||
|
|
@ -141,8 +66,6 @@ As you can see we, we're selecting all recipes where category is "Utilities".
|
|||
!!! info
|
||||
`abra app ls` lists apps grouped into a server object, with statistics about the server. In `jq` we can select the entire apps list with `.[].apps[]`.
|
||||
|
||||
```
|
||||
$ abra app ls -m -S |jq '[.[].apps[] | select(.status == "deployed") | del(.upgrade)]' |tv
|
||||
```
|
||||
`abra app ls -m -S |jq '[.[].apps[] | select(.status == "deployed") | del(.upgrade)]' |tv`
|
||||
|
||||
The `del(.upgrade)` filter filters out available versions for the recipe in question for that row. It could be useful to leave in if you want a list of deployed apps that need an upgrade.
|
||||
|
|
|
|||
|
|
@ -2,40 +2,14 @@
|
|||
title: Install
|
||||
---
|
||||
|
||||
## Installer script source
|
||||
|
||||
You can view that [here](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/scripts/installer/installer).
|
||||
|
||||
## Installer prerequisites
|
||||
|
||||
* `tar`
|
||||
* `wget`
|
||||
* `curl` (only if using `curl` method below)
|
||||
|
||||
## Stable release
|
||||
|
||||
### Wget
|
||||
|
||||
```
|
||||
wget -q -O - https://install.abra.coopcloud.tech | bash
|
||||
```
|
||||
|
||||
### Curl
|
||||
|
||||
```
|
||||
curl https://install.abra.coopcloud.tech | bash
|
||||
```
|
||||
|
||||
## Release candidate
|
||||
|
||||
### Wget
|
||||
|
||||
```
|
||||
wget -q -O - https://install.abra.coopcloud.tech | bash -s -- --rc
|
||||
```
|
||||
|
||||
### Curl
|
||||
|
||||
```
|
||||
curl https://install.abra.coopcloud.tech | bash -s -- --rc
|
||||
```
|
||||
|
|
@ -62,16 +36,20 @@ Otherwise, you downloaded a corrupted file and you should re-download it.
|
|||
|
||||
Follow the guide [here](https://docs.coopcloud.tech/abra/hack/)
|
||||
|
||||
## Installer script source
|
||||
|
||||
You can view that [here](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/scripts/installer/installer).
|
||||
|
||||
## Using Docker
|
||||
|
||||
```
|
||||
docker run \
|
||||
-v $HOME/.abra:/.abra \
|
||||
git.coopcloud.tech/coop-cloud/abra app ls
|
||||
-v $HOME/.abra:/.abra \
|
||||
git.coopcloud.tech/coop-cloud/abra app ls
|
||||
```
|
||||
|
||||
!!! note
|
||||
If you're using symlinks, e.g. for [sharing
|
||||
`~/.abra`](/operators/handbook/#sharing-abra), add more `-v` options for
|
||||
each directory you're symlinking to, e.g. `-v
|
||||
$HOME/Projects/CoopCloud/apps:/home/user/Projects/CoopCloud/apps`
|
||||
If you're using symlinks, e.g. for [sharing
|
||||
`~/.abra`](/operators/handbook/#sharing-abra), add more `-v` options for each
|
||||
directory you're symlinking to, e.g. `-v
|
||||
$HOME/Projects/CoopCloud/apps:/home/user/Projects/CoopCloud/apps`
|
||||
|
|
|
|||
|
|
@ -4,17 +4,15 @@ title: Membership
|
|||
|
||||
> Are you also interested in joining the federation? Please see [Resolution 002](/federation/resolutions/passed/002/) for our process on how to join. If you have any questions, [drop us a line](/intro/contact/) with us for a chat
|
||||
|
||||
| Name | Dues Paid | Notes | Contact |
|
||||
| --------- | --------- | -------- |-------- |
|
||||
| Agaric | - | - | `@wolcen:matrix.org` |
|
||||
| [Autonomic](https://autonomic.zone) | - | - | `@3wc`, `@cas`, `@knoflook`, `@travvy`, `@aadil` |
|
||||
| [Bonfire](https://bonfirenetworks.org) | - | - | `@mayel:matrix.org` + Ivan (`@cambriale:matrix.org`) |
|
||||
| [Doop.coop](https://doop.coop) | - | - | `@yusf:gottsnack.net` |
|
||||
| [EOTL](https://eotl.supply) | - | - | `@basebuilder:pub.solar` |
|
||||
| [Karrot](https://karrot.world) | - | - | `@nicksellen:matrix.org` |
|
||||
| [Klasse & Methode](https://codeberg.org/Klasse-Methode) | - | - | `@p4u1_f4u1:matrix.org` |
|
||||
| [Local IT](https://local-it.org/) | - | - | Philipp (`@yksflip:matrix.kaputt.cloud`) + `@moritz:matrix.local-it.org` |
|
||||
| Mirsal ™ | - | - | `@mirsal:1312.media` |
|
||||
| [UTAW](https://utaw.tech) | - | - | `@javielico:matrix.org` |
|
||||
| Name | Dues paid up? | Notes | Contact |
|
||||
| -------- | -------- | -------- |-------- |
|
||||
| Agaric | - | - | `@wolcen:matrix.org` |
|
||||
| Autonomic | - | - | `@3wc`, `@cas`, `@knoflook`, `@travvy`, `@aadil` |
|
||||
| Bonfire | - | - | `@mayel:matrix.org` + Ivan (`@cambriale:matrix.org`) |
|
||||
| Doop.coop | - | - | `@yusf:gottsnack.net` |
|
||||
| Klasse & Methode | - | - | `@p4u1_f4u1:matrix.org` |
|
||||
| Local IT | - | - | Philipp (`@yksflip:matrix.kaputt.cloud`) + `@moritz:matrix.local-it.org` |
|
||||
| Mirsal ™ | - | - | `@mirsal:1312.media` |
|
||||
| UTAW | - | - | `@javielico:matrix.org` |
|
||||
| [BeWater](https://bewater.contact) | Waiver | - | `@decentral1se` |
|
||||
| [ruangrupa](https://ruangrupa.id) | - | - | Henry `@babystepper:matrix.org` |
|
||||
| ruangrupa | - | - | Henry `@babystepper:matrix.org` |
|
||||
|
|
|
|||
|
|
@ -1,73 +0,0 @@
|
|||
---
|
||||
title: 2024-04-17
|
||||
---
|
||||
|
||||
## Meta
|
||||
|
||||
* Poll: https://poll.local-it.org/invite/Q828kjlYLNwW
|
||||
* Call: https://talk.local-it.org/rooms/nyy-z5y-yrh-sc2/join
|
||||
* Present: Local IT (moritz), EOTL (BaseBuilder, blu), BeWater(d1), Autonomic (Lai), Klasse & Methode (p4u1)
|
||||
|
||||
## Agenda
|
||||
|
||||
### First
|
||||
|
||||
* Fixed monthly Federation meeting (3rd Mon, etc) `@basebuilder`
|
||||
* Project re-organisation (recipes, tools, fedi repos) `@d1`
|
||||
* Backup specification `@p4u1`
|
||||
|
||||
### The Rest
|
||||
|
||||
* Non-Federation tasks specific bounty / funding `@basebuilder`
|
||||
* Website and docs work to better showcase federation - `@kawaiipunk`
|
||||
* https://git.coopcloud.tech/coop-cloud/organising/milestone/43
|
||||
* Recipe maintainence proposal - `@kawaiipunk`
|
||||
* "Hacking velocity = slow & money" (RE: recent fedi orga chat) `@d1`
|
||||
* Continuing budget 001 for meeting attendance, resolution 004 technically only covered 6 months to oct 2023 `@3wc` (but I won't be there)
|
||||
|
||||
## Notes
|
||||
|
||||
### Fixed monthly Federation meeting (3rd Mon, etc)
|
||||
|
||||
Talked about it couple of times, back and forth.
|
||||
- People who want to do regular can do that
|
||||
- Other people can do polled meeting
|
||||
- Poll every month is time consuming
|
||||
- Timezones is an issue
|
||||
|
||||
Poll options for meeting
|
||||
1. fix time/date every month
|
||||
1. fixed time/date with timezone wraparound (can be merged with 1. :)
|
||||
1. flexible every month (poll)
|
||||
1. fixed week with poll (day of week, crab.fit)
|
||||
|
||||
> crab.fit - software with heatmap of availability
|
||||
|
||||
### Project re-organisation (recipes, tools, fedi repos)
|
||||
|
||||
Problem: All projects are under one organisation (coop-cloud). Abra has to do a lot of work to figure out what is a recipe repo and what not. This got fixed but made recipe generation really slow
|
||||
|
||||
Proposal: 3 Organisations in gitea:
|
||||
- Recipes
|
||||
- Tools
|
||||
- Projects
|
||||
|
||||
What to look out for:
|
||||
- Redirects (mainly for recipes)
|
||||
- SSH will break though -> could make a migration script for that?
|
||||
|
||||
https://git.coopcloud.tech/coop-cloud/organising/milestone/45
|
||||
https://git.coopcloud.tech/coop-cloud/organising/issues/569
|
||||
|
||||
Maybe "tools" / "projects" not needed, only "recipes" / "other".
|
||||
|
||||
### Backup Specification
|
||||
|
||||
Needing to write operators and matainers guide
|
||||
|
||||
- [ ] should abra implement backup and restore or only provide an integration?
|
||||
- [ ] should we add a specification version?
|
||||
|
||||
## Next Meeting
|
||||
|
||||
* Who: ???
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 2024-03-29
|
||||
title: 2024-29-03
|
||||
---
|
||||
|
||||
## Meta
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
title: "Resolution 020"
|
||||
---
|
||||
|
||||
- Topic: Federation member responsibilities
|
||||
- Date: ...
|
||||
- Deadline: ...
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
Motivated by the last Federation meeting: [minutes](https://docs.coopcloud.tech/federation/minutes/2024-29-03/).
|
||||
|
||||
New members are joining the Federation, hurray! In the discussion about what it means to join, the question came up: what exactly are the responsibilities of the members? This was raised in [`#581`](https://git.coopcloud.tech/coop-cloud/organising/issues/581).
|
||||
|
||||
Responsibilities were defined in the original [Federation Proposal](https://pad.autonomic.zone/s/MLafJE2jC#Responsibilities). We would like to document and extend those in this proposal.
|
||||
|
||||
Furthermore, some existing members have not been participating, not paid dues/asked for waiver and some have even left the federation chat room. It would seem also time to define some "exit criteria" to keep a healthy balance.
|
||||
|
||||
### Details
|
||||
|
||||
#### Responsibilities
|
||||
|
||||
**Already agreed upon**
|
||||
|
||||
- Pay yearly dues or ask for waiver (if they can't afford it)
|
||||
- Actively participate in all large decisions
|
||||
- Agree to the [Code of Co-operation (CoC)](https://docs.coopcloud.tech/federation/code-of-coop/)
|
||||
|
||||
**New**
|
||||
|
||||
- Actively participate in monthly federation meetings. If they can't make it, updates will be sent by text.
|
||||
|
||||
#### Exit criteria
|
||||
|
||||
> The idea is not to eject people out the federation but to use these clear guidelines as a way to assess if participants should remain federation members. This applies to both sides as it is often unclear how to leave volunteer projects.
|
||||
|
||||
**New**
|
||||
|
||||
- Not paying dues / having an agreed waiver
|
||||
- Not actively participating in all large decisions
|
||||
- Not active in federation monthly meetings
|
||||
- Do not behave in accordance with the [CoC](https://docs.coopcloud.tech/federation/code-of-coop/)
|
||||
|
||||
#### Implementation
|
||||
|
||||
- These criteria + a link to the [Federation proposal](https://pad.autonomic.zone/s/MLafJE2jC) will be clearly linked on a new "Federation handbook" on docs.coopcloud.tech
|
||||
|
||||
- An agenda point will be put on the next federation meeting to chase up dues/waiver agreements and to agree on a collective process for checking on participation of members.
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
---
|
||||
title: "Resolution 021"
|
||||
---
|
||||
|
||||
- Topic: Budget XXX: Flag handling in Abra
|
||||
- Date: ...
|
||||
- Deadline: ...
|
||||
- Size: Medium
|
||||
|
||||
### Summary
|
||||
|
||||
Motivated by the collective release planning: [`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under "Argument Handling".
|
||||
|
||||
Due to a bug in the underlying library (`urfave/cli`) that Abra uses for command-line argument/flag handling, we have a bug in Abra which cannot be fixed without causing a breaking change. See [`#581`](https://git.coopcloud.tech/coop-cloud/organising/issues/581) for the ongoing discussion. This proposal is the TLDR; and proposal for the fix.
|
||||
|
||||
### Details (Budget XXX)
|
||||
|
||||
#### 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 `FATA[0000] <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.
|
||||
|
||||
#### Our solution
|
||||
|
||||
We propose to remedy this situation by upgrading `urfave/cli` to version 2 which enforces the "before" style. This was the solution from `urfave/cli` developers to fix their bug. You can then only do e.g.
|
||||
|
||||
```
|
||||
abra app deploy --chaos <domain>
|
||||
```
|
||||
|
||||
This is the "simplest" option in terms of development capacity and is the most cost effective option. The upgrade effort is more or less a known quantity, see [`#404`](https://git.coopcloud.tech/coop-cloud/abra/pulls/404) for more.
|
||||
|
||||
We have previously reverted from version 2 to version to 1 to maintain this flexibility. However, this leaves us with an unresolved bug which we want to close off.
|
||||
|
||||
#### Alternatives
|
||||
|
||||
If this restriction is seen as too burdensome, we see some alternatives.
|
||||
|
||||
If you choose to vote against this proposal, please include your preference for an alternative (below or with your own). This allows us to mount another proposal with minimal effort.
|
||||
|
||||
There is no guarantee we can get these right and it will incur an ongoing maintenance cost.
|
||||
|
||||
1. we make a special case hack in the case of the `--local` handling and proceed as usual
|
||||
1. we upgrade to v2 and include a patch which automatically re-orders "after" style options into the "before" style transparently
|
||||
|
||||
#### Budget
|
||||
|
||||
Compensate `@p4u1` for XXX hrs work to get this done. This includes XXX hrs
|
||||
backpay for the initial spike in
|
||||
[`#404`](https://git.coopcloud.tech/coop-cloud/abra/pulls/404).
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
---
|
||||
title: "Resolution 023"
|
||||
---
|
||||
|
||||
- Topic: Budget XXX: Improved project organisation
|
||||
- Date: ...
|
||||
- Deadline: ...
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
Motivated by the collective release planning: [`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under "Improved Project Organisation".
|
||||
|
||||
Several issues, both social & technical in nature are cominmg up based on our chocies for how to organise our project management in Co-op Cloud. This proposal will present the problems and proposals for solutions.
|
||||
|
||||
### Details (Budget XXX)
|
||||
|
||||
#### The problems
|
||||
|
||||
1. Because recipes and "other" repositories are gathered under a single Gitea organisation, [co-op cloud](https://git.coopcloud.tech/coop-cloud), `abra` has to do some serious acrobatics to understand what is a recipe and what is not a recipe. More details in [`#377`](https://git.coopcloud.tech/coop-cloud/organising/issues/377). See also [`#569`](https://git.coopcloud.tech/coop-cloud/organising/issues/569).
|
||||
1. Several participants have complained that there is too much indirection & noise involved in having a single issue tracker, [organising](https://git.coopcloud.tech/coop-cloud/organising/issues). By noise, we mean that, e.g. there are several conventions (labels, writing "Abra: " / "Docs: ") in marking issues related to different repositories. By indirection, we mean that it is not always clear where the issue relates to.
|
||||
1. There is an old Federation related organisation and related repository, [Federation](https://git.coopcloud.tech/Federation) which has raised questions from new members. It is not used now but it is still there.
|
||||
|
||||
#### The solutions
|
||||
|
||||
For the recipes issue:
|
||||
|
||||
1. Rename [co-op cloud](https://git.coopcloud.tech/coop-cloud) to "Co-op Cloud Configuration Commons (CCCC)".
|
||||
1. Create a new Gitea organisation called "Co-op Cloud Federation (CCF)".
|
||||
1. Migrate all "non recipe" repositories away from [co-op cloud](https://git.coopcloud.tech/coop-cloud) ("CCCC") and under the CCF organisation.
|
||||
|
||||
This creates a clear separation between the configuration commons AKA "the recipes" and "other stuff". This means that `abra` logic can be greatly simplified and become performant once again. Furthermore, we don't break any URLs by keeping the recipes where they always were. The renaming aspect is purely cosmetic, the recipe organisation URL will remain "co-op cloud".
|
||||
|
||||
Then, for the issue management issue:
|
||||
|
||||
1. Re-open all repository issue trackers instead of pointing to [organising](https://git.coopcloud.tech/coop-cloud/organising/issues).
|
||||
1. Migrate all issues by hand from `organising` to their relevant issue trackers. E.g. all issues in organising with the `abra` label will go to the `abra` issue tracker.
|
||||
1. Create a new repository called "Co-op Cloud Federation Coordination" where we have an issue tracker for specific federation discussions (E.g. "tracking every member paying dues").
|
||||
1. Create a single Gitea Project under the CCF organisation called "Federation FTW".
|
||||
|
||||
"Federation FTW" will be the project we collectively refer to in our federation meetings as the "main list of priorities". Issues from every part of the project can be referenced there in a single place. Discussions can happen decentrally in their own issue trackers. It is the central source of truth for our current priorities and a way to stay up to date with what we want to do in the short to medium term.
|
||||
|
||||
#### Budget
|
||||
|
||||
* 5 hrs for migrating labours of the issues to their related issue trackers.
|
||||
* Additional 3 hrs for unseen migration / busy work gotchas.
|
||||
* 4 hrs for `abra` changes to only parse the new recipes repository
|
||||
* Total: 12 hrs
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
---
|
||||
title: "Resolution 022"
|
||||
---
|
||||
|
||||
- Topic: Budget 10: Abra integration suite automation
|
||||
- Date: 04-04-2024
|
||||
- Deadline: 18-04-2024
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
Motivated by the collective release planning:
|
||||
[`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under
|
||||
"Automate Integration Test Suite".
|
||||
|
||||
The latest `abra` release (`0.9.x`) was heavily delayed due to several issues.
|
||||
One of those was the need to fix the integration test suite which wasn't run in
|
||||
some time. Many breakages had crept into the test suite over time. This can
|
||||
avoided in the future by automating the running of the integration test suite.
|
||||
|
||||
This proposal describes a way to do this and includes a budget for doing so.
|
||||
|
||||
### Details (Budget 10)
|
||||
|
||||
The `abra` test suite takes around 1.30 hrs to run on a modest machine.
|
||||
Therefore, we propose to run it only once daily. Some parts of the tests are
|
||||
slow, fast and only a few require public DNS. This means we can break up the
|
||||
tests and run them in separate "builds" to speed things up. This involves some
|
||||
research & experimentation.
|
||||
|
||||
A server has been provided by `@mirsal` on donation (💘). This machine will be
|
||||
be wiped clean each day (`docker <command> prune ....`) and will have the usual
|
||||
DNS machinery attached to it, e.g. `int.coopcloud.tech`, `*.int.coopcloud.tech`.
|
||||
|
||||
Once that is all wired up, we can implement the CI/CD configuration to make the
|
||||
test suite run automatically once a day. This will be triggered via the
|
||||
`.drone.yml` in the `abra` Git repository.
|
||||
|
||||
Budget details:
|
||||
|
||||
| Item | Cost | Who? |
|
||||
| ---- | ---- | ---- |
|
||||
| Server | Free (on donation) | `@mirsal` |
|
||||
| Server setup & docs | 1 hour | `@d1` |
|
||||
| R & D for breaking up tests | 5 hours | `@d1` |
|
||||
| Implementing CI/CD configs | 10 hours | `@d1` |
|
||||
|
||||
**Total: 16 hrs * 20 EUR = 320 EUR**
|
||||
|
|
@ -696,21 +696,6 @@ You should be able to deploy this overriden configuration now.
|
|||
|
||||
## Linting rules
|
||||
|
||||
### R015: "long secret names"
|
||||
|
||||
Due to limitations placed by the Docker runtime, secret names must be < 64
|
||||
characters long. Due to convetions in recipe configuration and how `abra`
|
||||
works, several characters are appended to secret names during a deployment.
|
||||
This means if you have a domain `example.org` and a secret `foo_pass`, you'll
|
||||
end up with something like `example_org_foo_pass_v1` being used for the secret
|
||||
name.
|
||||
|
||||
Based on a discussion in
|
||||
[`#463`](https://git.coopcloud.tech/coop-cloud/organising/issues/463) and
|
||||
looking on what is implemented currently in existing recipes, we came up with a
|
||||
general rule of thumb that secret names in recipe configurations should be < 12
|
||||
characters long to avoid errors on deployment.
|
||||
|
||||
### R014: "invalid lightweight tag"
|
||||
|
||||
This is an issue related to the way Git/`go-git` handle Git tags internally. We
|
||||
|
|
|
|||
|
|
@ -317,20 +317,9 @@ See [`#312`](https://git.coopcloud.tech/coop-cloud/organising/issues/312) for mo
|
|||
|
||||
If you're app [supports backup/restore](/maintainers/handbook/#how-do-i-configure-backuprestore) then you have two options: [`backup-bot-two`](https://git.coopcloud.tech/coop-cloud/backup-bot-two) & [`abra`](https://git.coopcloud.tech/coop-cloud/abra).
|
||||
|
||||
With `abra`, you can simply run the commands:
|
||||
|
||||
```
|
||||
$ abra app backup <domain>
|
||||
$ abra app restore <domain>
|
||||
```
|
||||
|
||||
With `abra`, you can simply run `abra app backup ...` & `abra app restore ...`.
|
||||
Pass `-h` for more information on the specific flags & arguments.
|
||||
|
||||
If your app Recipe *does not support backups* you can do it manually with the
|
||||
`abra cp` command. See the exact commands in [abra
|
||||
cheetsheet](/abra/cheat-sheet/#manually-restoring-app-data).
|
||||
|
||||
|
||||
## How do I take a manual database backup?
|
||||
|
||||
MySQL / MariaDB:
|
||||
|
|
@ -460,23 +449,3 @@ route requests after. You're free to make as many `$whatever.yml` files in your
|
|||
|
||||
Yes, it's possible although currently Quite Experimental! See
|
||||
[`#388`](https://git.coopcloud.tech/coop-cloud/organising/issues/388) for more.
|
||||
|
||||
## Running an offline coop-cloud server
|
||||
|
||||
You may want to run a coop-cloud directly on your device (or in a VM or machine on your LAN), whether that's for testing a recipe or to run coop-cloud apps outside of the cloud ;-)
|
||||
In that case you might simply add some names to `/etc/hosts` (e.g `127.0.0.1 myapp.localhost`), or configure them on a local DNS server - which means `traefik` won't be able to use `letsencrypt` to generate and verify SSL certificates. Here's what you can do instead:
|
||||
1. In your traefik .env file, edit/uncomment the following lines:
|
||||
```
|
||||
LETS_ENCRYPT_ENV=staging
|
||||
WILDCARDS_ENABLED=1
|
||||
SECRET_WILDCARD_CERT_VERSION=v1
|
||||
SECRET_WILDCARD_KEY_VERSION=v1
|
||||
COMPOSE_FILE="$COMPOSE_FILE:compose.wildcard.yml"
|
||||
```
|
||||
2. Generate a self-signed certificate using the [command listed here](https://letsencrypt.org/docs/certificates-for-localhost/#making-and-trusting-your-own-certificates). Unless using `localhost` you may want to edit that where it appears in the command, and/or add multiple (sub)domains to the certificate e.g: `subjectAltName=DNS:localhost,DNS:myapp.localhost`
|
||||
3. Run these commands:
|
||||
```
|
||||
abra app secret insert localhost ssl_cert v1 "$(cat localhost.crt)"
|
||||
abra app secret insert localhost ssl_key v1 "$(cat localhost.key)"
|
||||
```
|
||||
4. Re-deploy `traefik` with `--force` and voila!
|
||||
|
|
|
|||
|
|
@ -139,21 +139,15 @@ abra server ls
|
|||
|
||||
In order to have your Co-op cloud deployment serve the public internet, we need to install the core web proxy, [Traefik](https://doc.traefik.io/traefik/).
|
||||
|
||||
Traefik is the main entrypoint for all web requests (e.g. like NGINX) and
|
||||
supports automatic SSL certificate configuration and other quality-of-life
|
||||
features which make deploying libre apps more enjoyable.
|
||||
Traefik is the main entrypoint for all web requests (e.g. like NGINX) and supports automatic SSL certificate configuration and other quality-of-life features which make deploying libre apps more enjoyable.
|
||||
|
||||
**1. To get started, you'll need to create a new app:**
|
||||
To get started, you'll need to create a new app:
|
||||
|
||||
```bash
|
||||
abra app new traefik
|
||||
```
|
||||
|
||||
Choose your newly registered server and specify a domain name. By default `abra`
|
||||
will suggest `<app-name>.server.org` or prompt you with a list of servers.
|
||||
|
||||
|
||||
**2. Configure this new `traefix` app**
|
||||
Choose your newly registered server and specify a domain name.
|
||||
|
||||
You will want to take a look at your generated configuration and tweak the `LETS_ENCRYPT_EMAIL` value. You can do that by running `abra app config`:
|
||||
|
||||
|
|
@ -161,32 +155,14 @@ You will want to take a look at your generated configuration and tweak the `LETS
|
|||
abra app config <traefik-domain>
|
||||
```
|
||||
|
||||
Every app you deploy will have one of these `.env` files, which contains
|
||||
variables which will be injected into app configurations when deployed. These
|
||||
files exist at relevantly named path:
|
||||
Every app you deploy will have one of these `.env` files, which contains variables which will be injected into app configurations when deployed. Variables starting with `#` are optional, others are required.
|
||||
|
||||
```bash
|
||||
~/.abra/servers/<domain>/<traefik-domain>.env
|
||||
```
|
||||
|
||||
Variables starting with `#` are optional, others are required. Some things to
|
||||
consider here is that by default our *Traefik* recipe exposes the metric
|
||||
dashboard unauthenticated on the public internet at the URL `<traefik-domain>`
|
||||
it is deployed to, which is not ideal. You can disable this with:
|
||||
|
||||
```
|
||||
DASHBOARD_ENABLED=false
|
||||
```
|
||||
|
||||
**3. Now it is time to deploy your app:**
|
||||
Now it is time to deploy:
|
||||
|
||||
```
|
||||
abra app deploy <traefik-domain>
|
||||
```
|
||||
|
||||
Voila. Abracadabra :magic_wand: your first app is deployed :sparkles:
|
||||
|
||||
|
||||
### Deploy Nextcloud
|
||||
|
||||
And now we can deploy apps. Let's create a new Nextcloud app.
|
||||
|
|
|
|||
10
mkdocs.yml
10
mkdocs.yml
|
|
@ -125,18 +125,16 @@ nav:
|
|||
- federation/resolutions/passed/015.md
|
||||
- federation/resolutions/passed/016.md
|
||||
- federation/resolutions/passed/017.md
|
||||
- federation/resolutions/passed/018.md
|
||||
- federation/resolutions/passed/019.md
|
||||
- "In Progress":
|
||||
- federation/resolutions/in-progress/013.md
|
||||
- federation/resolutions/in-progress/022.md
|
||||
- federation/resolutions/in-progress/018.md
|
||||
- federation/resolutions/in-progress/019.md
|
||||
- "Minutes":
|
||||
- federation/minutes/index.md
|
||||
- "Recently":
|
||||
- federation/minutes/2024-04-17.md
|
||||
- federation/minutes/2024-03-29.md
|
||||
- "Archive":
|
||||
- federation/minutes/2024-29-03.md
|
||||
- federation/minutes/2024-02-01.md
|
||||
- "Archive":
|
||||
- federation/minutes/2022-03-03.md
|
||||
- federation/minutes/2023-05-03.md
|
||||
- "Digital Tools": federation/tools.md
|
||||
|
|
|
|||
Loading…
Reference in New Issue