Recipe repository local listing for version skipping (like apt) #186
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: coop-cloud/organising#186
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?
Describe the problem to be solved
How to skip upgrades when doing non-interactive tag upgrading?
E.g. skipping mysql upgrade X when doing upgrades
Describe the solution you would like
Some
$x
file in the recipe repo thatabra
reads and takes into account when doingabra recipe ...
commands./cc @knoflook
this seems easy enough: just use an easily parsable format like yaml to create a blacklist i.e.
would prevent upgrading nextcloud to 22.0.1-fpm, but would allow cron to use this image. and we could have a 'global' keyword or something simillar to prevent any container from using this specific version of an app. Or we can do away with the container name alltogether and go with:
or we can do
which would prevent any container to use a nextcloud image tagged with version 22.0.1-fpm
maybe slap some wildcard features on it so if you despise alpine you can make sure you're not using alpine containers.
or we could go a different route and bind to specific version of packages to keep them from being upgraded so
would mean that you want those versions to stay when upgrading. I dunno this idea needs futher work
Hmmm, yes indeed. Perhaps just a text file to start?
Something real simple to parse would be handy.
Also to note, there is a colonial language issue with whitelist/blacklist.
There was also a proposal to use
--service/-s
n+1 flag to target which service you want to upgrade for. That might be handy on its own. I like this file based approach very much though and it seems more powerful for managing skipping.ahh yes, thanks for pointing it out! Then we can have pin/hold + skip keywords for when you want to pin to a specific version (or in other words hold it) and for when you know a specific version is buggy and you want to skip it.
my problem with this approach is that the actual image that we use might change, moving from mariadb to postgresql for instance and this would skip an upgrade in both cases. So if it's left lingering in a text file that might cause problems.
skip db mariadb:10.6
orskip db mariadb 10.6
is better imo as it's impossible to mistake.and hey this is a pretty good format if you ask me
just read it line by line, do a string.Split() on every line and there you go. it's even simpler than yaml
pin
is also good for when we want to maintain 2 versions of the same app simultaneously e.g. nextcloud 21 and 22 you could just dopin app nextcloud 21
to make sure it won't be upgraded to 22
Damnit that is looking very useful 🚀 The last proposal LGTM!
@3wordchant, thoughts on #186 (comment)? We're trying to solve the question of "How to skip upgrades when doing non-interactive tag upgrading?".
This could be tested out on coop-cloud/keycloak#8.
Seems brilliant!
I'm much more likely to need
pin
, to the point of not really being able to imagine the use-case forskip
, so maybe I'm missing something.Imagining
mariadb:10.6
is a lemon, I could do either:pin db mariadb 10.5
skip db mariadb 10.6
Am I right that if I did (2), abra would automatically assume that a new
10.7
version is OK? I feel like I would always use (1) then, to make sure we only upgraded to 1.7 once some human had tested it was actually working.Yeah true, lets just use
pin
!