Collective maintenance often means hidden app upgrades #434
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
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/organising#434
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
Hinted at in coop-cloud/organising#338 but the penny finally dropped. The collective mainteannce case is actually pretty unstable. We've been silently upgrading apps for months probably 😆
I have spent a good deal of time thinking about how to deal with this such that redeploys always use the same version unless otherwise specified, and I think I have a pretty good idea about how to do it.
We should record the version of the recipe in the .env file since this is the only state we store that's not in the docker demon. This would also allow us to start defining the shape of how to describe source/recipe/version information for adding additional/better sources (I've been thinking about this a while too).
I feel like what we should do is replace the
TYPEenvironment variable with something likeCOOP_RECIPE, and add version information. We can it only change theCOOP_RECIPEif aabra app upgradeis performed (or the user updates it manually).I think the syntax should be something like
source:type:version, (egccf:gitea:2.0.1+1.18.2-rootless) but we need to have some sort of semantics for parsing these and having parts missing for user convenience. We should also just leave out the source for now but keep it in mind for future.Perhaps
--chaoswould imply using the current checked-out version, and update the version field to something likelocal-shorthashso it could be redeployed with that version (given your local repository has that hash).For bug compatibility, a TYPE variable could specify the most current version of the recipe, but as soon as it's deployed with the current version a COOP_RECIPE should be added to the config.
Nice @cas!
Does the
ccfin theccf:gitea:2.0.1+1.18.2-rootlessdo something? My assumption is thatsourceleaves the door open for other recipes catalogues or? Should that correspond to a URL or something?TYPEis currently a static string set in the.envfiles to mark the recipe name.COOP_RECIPEwould be a dynamic string? What would be the default string for new recipes? I guess we could do a search/replace onrecipe newfor latest catalogue version.There is potential for a bikeshed on
COOP_RECIPEsince there is more than the recipe name contained in it. Even more than the version in your proposal. It's more like aRECIPE_SPEC😄We could have
abrasupportTYPE/COOP_RECIPEin parallel while things switch over. This will cost us some time to implement. So, I guess we can come up with a proposal to raise awareness about it to the rest of the federation.--chaosshorthash logic soundds good.To be a little clearer:
My idea is that the
ccfis the "source". It should be left out for the time being. The source would be basically a label attached to a recipe catalog URL. The idea being that at some point we will want to support an arbitrary collection of sources.TYPEshould be changed into a dynamic string created from theCOOP_RECIPEwhich would be effectively set by the maintainer of the recipe (so that any given deployment would be stuck to a particular version unless intentionally upgraded).I think that supporting both as a transitional stage is important. I think my outline as to how deployments could be transitioned to the recipe specifier would work but it should perhaps warn the user and prompt for the pinning/upgrade step to happen (so if your app deployment has a TYPE specifier, it would say "Hay, we're moving to COOP_RECIPE so that things don't get upgraded unexpectedly on deploy, is it ok to pin your deployment at
<VERSION>? You can upgrade later withupgrade".@cas I'm fine with including the source for now but we might wanna sketch out how it is used first to avoid more breaking changes. The need for decentralised catalogue support is coming up again and again. Maybe
ccfis just a key in~/.abra/catalogue/recipes.jsonor a filename~/.abra/catalogue/ccf.json🤷♀️FYI @cas I'm gonna try bring this to discussion in the coming fedi meeting (date poll coming another day for date/time, see matrix for more). Would you be up for working on this in some capacity? I'd be down to help either in implementation or testing against an implementation. I'd love to see us make progress here because it's such a huge issue.
I'm 1000% up for working on this, since it bites us every time i have to do maintenance or whatever it's just real annoying.
This would also solve coop-cloud/organising#440 updating only the .env file using
abra app deploy -fwithout changing the deployed recipe version.I can think of issues if the local
COOP_RECIPEversion tag and the deployed version differs for some reasons. There should be a check if both versions are equal and if they differ set theCOOP_RECIPEto the deployed version.I'm starting to think some part of coop-cloud/organising#467 is a prerequisite for this. Because, yeh, if we're updating a
COOP_RECIPEbut not syncing it to a remote (and syncing it on other machines of fellow workers), then it's next to useless?I'm gonna try to draw up a proposal for this because it's getting kinda convoluted in my brain 😆
I agree having the data stored somewhere would be useful. i haven't thought about thisl for a bit but my assumption is that the operators would be handling that pathway on their own anyway so that would take care of synchronizing for them. I don't think it's next to useless, because it still constrains the way abra will act, but I see the argument that we should be providing a mechanism for obtaining that information if not directly from the server in question, then somewhere.
@cas Sorry, that was poorly worded on my part. I don't know why I used that phrasing ("useless") 🤔 Certainly not.
So, yes, that's it. For the individual operator, the
COOP_RECIPEwill help them pin deploys. But without sync, it will not help a team pin deploys.Once I realised that, I ended up on coop-cloud/organising#467 and then coop-cloud/organising#267 (comment) which are all good ideas.
I think we need to have a collective design discussion on this one whenever the next meet happens.
Merging into coop-cloud/organising#467 👍