Operator collaboration #467
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#467
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hey,
As mentioned in the sharing abra - you're on your own! section, sharing server folders via git repos is a manual process.
This is very error prone and I forget it all the time. Ofc we could write some Makefile or anything to supplement this, but I think this would be nice for abra to have.
Also we tried to keep a manual Changelog for each server wich is very tedious! Couldn't abra also do that with a good git history?
here the rough idea:
abra server add foointroduces a git repo url parameter
abra app new foogit add / commit / push the new .env file
abra app configgit add / commit / push the modified .env file
abra app deploygit commit --allow-empty -m "some useful informations about the deployment here?"abra server changelogcould show a
git logwith all the changes from a serverabra app changelogshows the
git logof a individual appmaybe some command to leave a custom message
and absolutely
git pullall the time.this relates to #267 #271
Wow, yeh, that could be incredibly useful for collectively doing stuff. I can just imagine all the
go-gitbugs now 😆 For theabra server add foo: introduces a git repo url parameter, i'm wondering how to support the "all the server files in one repo" use case which is maybe more of what #267 is going for. Love the git command design so far!Yeh just not having a way to remember what was previously deployed is such a drag. I forget all the time instantly after deploying something and then am lost in the entropy. Idk where this complaint should go but I think solving just that, whether with Git or some other way via ideas in https://docs.coopcloud.tech/operators/handbook/#sharing-abra would be amazing.
#434 (comment)
operator collaboration / syncing the server directory / server changelogto Operator collaboration@yksflip how will we deal with merge conflicts? Just bail out gracefully and be like "ok, now you're on your own again until you solve this shit"?
I've got a proposal WIP for this https://pad.riseup.net/p/VewCbdPI-_RWR7ooe6v0-keep
hmm, I guess so. I mean hopefully there wont be many conflicts as we perform
git pullall the time? But stuff will go wrong and I think then it's the best to let the operator fix things and not assume anything.Proposal looks great! nice you're tackling this :)
A wild doubt appears #267 (comment)
There should be a flag to deactivate this functionality to avoid loads of pushed commits while tinkering with configs. I would prefer to only commit a finished config instead of committing each little config changes (many undos and redos). And maybe an
abra server commitcommand if you edit files manually.If adding the repo url is at server add time, and it is optional, and it can be added to the server after the server has been created without one (by either just git init in the server's directory, or putting it into a git repository, or with an abra command), and commits/pushes are on demand rather than cooked into other operations without an additional flag to those operations (so that tinkering, the setup loop, and other things don't create a ton of commits), I'm in favor of this mechanic. I could see warning if an operation would not commit/push the changes to the env file or if it's been N hours since a commit/push has been done and there are changes.
I think a bonus point would be to also create a remote on the server in question (again, at the operators discretion) so that abra could discover not only the canonical remote for that server but also the configurations for that server at
abra add servertime (for example if I switched my computer but forgot to bring my abra config).Yeh, nice. The more explicit invocation of syncing could be a way to go. Still need to think this through...
Super interesting idea! I would love to have a way to bootstrap a shared SSH config into a developer machine (imagine a
Include ~/.abra/ssh/configwhich is appended to the~/.ssh/config?) and having a way to grab server configurations (one or all) could potentially really speed up onboarding to get access...@cas @moritz @yksflip @3wordchant et. al here is a design proposal:
Feedback welcome!
I went for a trimmed down version, focusing on syncing the version of the app for the
deploy/upgrade/rollbackcommands.It isn't on demand as you mentioned @cas as I fear folks might forget to sync the versions manually. The compromise is that there is much less syncing going on than in the original design above. Sync of other details could certainly be on demand in future.
Can move towards a resolution/budget if consensus starts to emerge 🌞
UPDATE: https://docs.coopcloud.tech/federation/resolutions/in-progress/013/
great! I think this should tackle the overall pain points :)
The proposal is still under consideration, there seems to be some concerns around it still. Polling for support in the federation channel. Please also see latest minutes: https://pad.autonomic.zone/dKJl5gKVStiV1yGmK-ya9Q?both
decentral1se referenced this issue2024-03-12 09:54:24 +00:00