Recipe repository local listing for version skipping (like apt) #186

New Issue

2021-10-07T14:12:08Z

decentral1se commented

2021-10-07 14:12:08 +00:00

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 that abra reads and takes into account when doing abra recipe ... commands.

/cc @knoflook

## 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 that `abra` reads and takes into account when doing `abra recipe ...` commands. /cc @knoflook

decentral1se added this to the (deleted) milestone 2021-10-07 14:12:08 +00:00

decentral1se added the enhancement abra labels 2021-10-07 14:12:08 +00:00

knoflook commented

2021-10-07 17:23:13 +00:00

this seems easy enough: just use an easily parsable format like yaml to create a blacklist i.e.

app:
  nextcloud:
    22.0.1-fpm
db:
  mariadb:
     10.6   (this would block 10.6.z as well i think)

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:

app:
  22.0.1-fpm
db:
  10.6

or we can do

services:
  db:
    mariadb:
      10.6
            
global:
  nextcloud:
    22.0.1-fpm

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

app:
  22.0.1-fpm
db:
  10.6

would mean that you want those versions to stay when upgrading. I dunno this idea needs futher work

this seems easy enough: just use an easily parsable format like yaml to create a blacklist i.e. ``` app: nextcloud: 22.0.1-fpm db: mariadb: 10.6 (this would block 10.6.z as well i think) ``` 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: ``` app: 22.0.1-fpm db: 10.6 ``` or we can do ``` services: db: mariadb: 10.6 global: nextcloud: 22.0.1-fpm ``` 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 ``` app: 22.0.1-fpm db: 10.6 ``` would mean that you want those versions to stay when upgrading. I dunno this idea needs futher work

decentral1se commented

2021-10-08 07:29:54 +00:00

Hmmm, yes indeed. Perhaps just a text file to start?

skip app 22.0.1-fpm
skip db 10.6

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.

Hmmm, yes indeed. Perhaps just a text file to start? ``` skip app 22.0.1-fpm skip db 10.6 ``` 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.

knoflook commented

2021-10-11 08:34:21 +00:00

Also to note, there is a colonial language issue with whitelist/blacklist.

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.

skip db 10.6

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 or skip 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

pin <container name> <image name> <version>
skip <container name> <image name> <version>

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 do
pin app nextcloud 21
to make sure it won't be upgraded to 22

>Also to note, there is a colonial language issue with whitelist/blacklist. 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. >`skip db 10.6` 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` or `skip 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 ``` pin <container name> <image name> <version> skip <container name> <image name> <version> ``` 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 do `pin app nextcloud 21` to make sure it won't be upgraded to 22

decentral1se commented

2021-10-11 11:39:17 +00:00

Damnit that is looking very useful 🚀 The last proposal LGTM!

@3wordchant, thoughts on coop-cloud/organising#186 (comment)? We're trying to solve the question of "How to skip upgrades when doing non-interactive tag upgrading?".

Damnit that is looking very useful 🚀 The last proposal LGTM! @3wordchant, thoughts on https://git.coopcloud.tech/coop-cloud/organising/issues/186#issuecomment-9321? We're trying to solve the question of "How to skip upgrades when doing non-interactive tag upgrading?".

decentral1se commented

2021-10-21 07:46:36 +00:00

This could be tested out on coop-cloud/keycloak#8.

This could be tested out on https://git.coopcloud.tech/coop-cloud/keycloak/issues/8.

3wordchant commented

2021-10-24 14:26:02 +00:00

Seems brilliant!

I'm much more likely to need pin, to the point of not really being able to imagine the use-case for skip, 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.

Seems brilliant! I'm much more likely to need `pin`, to the point of not really being able to imagine the use-case for `skip`, so maybe I'm missing something. Imagining `mariadb:10.6` is a lemon, I could do either: 1. `pin db mariadb 10.5` 2. `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.

decentral1se commented

2021-10-25 09:32:06 +00:00

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!

> 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`!

👍 1

knoflook self-assigned this 2021-10-31 11:59:58 +00:00

knoflook referenced this issue from a commit

2021-11-01 10:33:58 +00:00

feat: add recipe version pinning

knoflook referenced this issue from toolshed/abra

2021-11-01 10:35:49 +00:00

feat: add recipe version pinning #120

decentral1se referenced this issue from a commit

2021-11-03 05:28:24 +00:00

feat: add recipe version pinning

decentral1se closed this issue