Add a warning about bumping postgres versions during abra recipe upgrade #597

Open
opened 2024-03-30 15:18:23 +00:00 by 3wordchant · 9 comments
Owner

Accepting a Postgres major version upgrade during abra recipe upgrade causes pain, it needs something like coop-cloud/outline#15 added to the recipe otherwise apps won't be able to start post-upgrade.

It would be nice to have a warning about this.

Not sure how to make this generic – are there any other images which will always cause a problem during app upgrade unless workarounds are deployed, especially ones which are used in many recipes?

Accepting a Postgres major version upgrade during `abra recipe upgrade` causes pain, it needs something like https://git.coopcloud.tech/coop-cloud/outline/pulls/15 added to the recipe otherwise apps won't be able to start post-upgrade. It would be nice to have a warning about this. Not sure how to make this generic – are there any other images which will always cause a problem during `app upgrade` unless workarounds are deployed, especially ones which are used in many recipes?
3wordchant added the
enhancement
label 2024-03-30 15:18:23 +00:00
Author
Owner
CC @kawaiipunk
Owner

Isn't this just one for the recipe release notes where you can load in your own scary warning?

Isn't this just one for the recipe release notes where you can load in your own scary warning?
Author
Owner

@decentral1se that's fine as long as the comrade running abra recipe upgrade <foobar> knows about the postgres situation, or does an organised test before running abra recipe release… ways to make both of those more likely could help of course!

@decentral1se that's fine as long as the comrade running `abra recipe upgrade <foobar>` knows about the postgres situation, or does an organised test before running `abra recipe release`… ways to make both of those more likely could help of course!
Member

I really want to avoid having anything postgress specific. But it would be nice to have this generic. So every time a maintainer runs abra recipe upgrade it checks for major upgrades an warns about them.

Another radical option would be to remove the whole dependency update stuff from abra and rely on something like renovate for updating dependencies. This would also have the benefit of getting notifications for dependency updates

I really want to avoid having anything postgress specific. But it would be nice to have this generic. So every time a maintainer runs `abra recipe upgrade` it checks for major upgrades an warns about them. Another radical option would be to remove the whole dependency update stuff from abra and rely on something like renovate for updating dependencies. This would also have the benefit of getting notifications for dependency updates
Owner

Proposal: add additional INFO level logging for the type of upgrade abra discovers in abra app upgrade. This could be an additional field in the upgrade overview table, PATCH / MINOR / MAJOR.

To discuss: I would also not be against adding a link to the docs for a "what to do when you see a MAJOR upgrade" which would say things like "do you have Postgres hell incoming? Check!" That entry could just be a bunch of tips for all sorts of gotchas that can happen on a major version upgrade.

Proposal: add additional INFO level logging for the *type* of upgrade `abra` discovers in `abra app upgrade`. This could be an additional field in the upgrade overview table, `PATCH` / `MINOR` / `MAJOR`. To discuss: I would also not be against adding a link to the docs for a "what to do when you see a `MAJOR` upgrade" which would say things like "do you have Postgres hell incoming? Check!" That entry could just be a bunch of tips for all sorts of gotchas that can happen on a major version upgrade.
Author
Owner

I really want to avoid having anything postgress specific. But it would be nice to have this generic. So every time a maintainer runs abra recipe upgrade it checks for major upgrades an warns about them.

I generally agree with you @p4u1. And I realise I left the last sentence of the ticket unfinished; maybe it makes more sense with that clarification:

Not sure how to make this generic – are there any other images which will always cause a problem during app upgrade unless workarounds are deployed, especially ones which are used in many recipes?


Proposal: add additional INFO level logging for the type of upgrade abra discovers in abra app upgrade. This could be an additional field in the upgrade overview table, PATCH / MINOR / MAJOR.

My suggestion here is about a warning to maintainers (abra recipe upgrade) not operators (abra app upgrade); if a maintainer already knows about the potential issues with a Postgres upgrade then indeed they can add a release note – but not all do, and I'm suggesting trying to fix that.

To discuss: I would also not be against adding a link to the docs for a "what to do when you see a MAJOR upgrade" which would say things like "do you have Postgres hell incoming? Check!" That entry could just be a bunch of tips for all sorts of gotchas that can happen on a major version upgrade.

Yeah for sure if we can't agree on anything else then docs are a fine fallback (or an addition if we can). But I am still nervous (especially given that every other major image version upgrade that a maintainer sees will be chill and fine) that this advice will be missed / forgotten.

Another radical option would be to remove the whole dependency update stuff from abra and rely on something like renovate for updating dependencies. This would also have the benefit of getting notifications for dependency updates

Think the discussion in #599 is going well, thanks for starting it! 🙏 I'd personally like to keep this issue open, because even if we switch to renovate or something I think a warning for Postgres (and any other similar images with the same issue) would be extremely helpful.

> I really want to avoid having anything postgress specific. But it would be nice to have this generic. So every time a maintainer runs `abra recipe upgrade` it checks for major upgrades an warns about them. I generally agree with you @p4u1. And I realise I left the last sentence of the ticket unfinished; maybe it makes more sense with that clarification: > Not sure how to make this generic – are there any other images which **will always cause a problem during `app upgrade` unless workarounds are deployed, especially ones which are used in many recipes?** --- > Proposal: add additional `INFO` level logging for the type of upgrade abra discovers in abra app upgrade. This could be an additional field in the upgrade overview table, `PATCH` / `MINOR` / `MAJOR`. My suggestion here is about a warning to maintainers (`abra recipe upgrade`) not operators (`abra app upgrade`); if a maintainer already knows about the potential issues with a Postgres upgrade then indeed they can add a release note – but not all do, and I'm suggesting trying to fix that. > To discuss: I would also not be against adding a link to the docs for a "what to do when you see a MAJOR upgrade" which would say things like "do you have Postgres hell incoming? Check!" That entry could just be a bunch of tips for all sorts of gotchas that can happen on a major version upgrade. Yeah for sure if we can't agree on anything else then docs are a fine fallback (or an addition if we can). But I am still nervous (especially given that every other major image version upgrade that a maintainer sees will be chill and fine) that this advice will be missed / forgotten. > Another radical option would be to remove the whole dependency update stuff from abra and rely on something like renovate for updating dependencies. This would also have the benefit of getting notifications for dependency updates Think the discussion in #599 is going well, thanks for starting it! 🙏 I'd personally like to keep this issue open, because even if we switch to renovate or something I think a warning for Postgres (and any other similar images with the same issue) would be extremely helpful.
Owner

My suggestion here is about a warning to maintainers (abra recipe upgrade) not operators (abra app upgrade);

Oh! Yes, I seeeeee. Thanks for explanation labours. Then that seems pretty doable perhaps. We can parse most image tags and check if it they're a major upgrade and warn. To keep it general? If not, we can warn and say "unable to parse, please check if this major yourself?". Might take some wrangling to only ouput a single warning instead of per-image warning but shouldn't be too hard.

If that is all too much, not really totally against special-casing a postgres warning...

> My suggestion here is about a warning to maintainers (abra recipe upgrade) not operators (abra app upgrade); Oh! Yes, I seeeeee. Thanks for explanation labours. Then that seems pretty doable perhaps. We can parse most image tags and check if it they're a major upgrade and warn. To keep it general? If not, we can warn and say "unable to parse, please check if this major yourself?". Might take some wrangling to only ouput a single warning instead of per-image warning but shouldn't be too hard. If that is all too much, not really totally against special-casing a postgres warning...
Author
Owner

Likewise thanks for thoughts!

We can parse most image tags and check if it they're a major upgrade and warn.

I don't think the criterion is / should be "is it a major Docker image upgrade", though, I think it is (from recently-updated issue description) "images which will always cause a problem during app upgrade unless workarounds are deployed, especially ones which are used in many recipes?".

We have over 200 different docker images used across Co-op Cloud recipes¹ (🤯🤯🤯) and as far as I know Postgres is the only one which causes breaking changes on every major version upgrade. Adding a warning for the ~200 other images seems it would create a lot of noise for recipe maintainers, that would like train people into ignoring the actually-critical Postgres ones.

The only other semi-related case I think of where a warning might be helpful are recipes like minio where we're deliberately holding back a docker image upgrade because there's a specific hellish major version upgrade, or discourse where there are some bogus high-numbered tags that don't represent real software versions – but neither of those is a problem with every major image version.

¹rg -NI --no-heading 'image:' | cut -d':' -f2 | sed -e 's/"//g' -e 's/^[[:space:]]*//' | sort -u

Likewise thanks for thoughts! > We can parse most image tags and check if it they're a major upgrade and warn. I don't think the criterion is / should be "is it a major Docker image upgrade", though, I think it is (from recently-updated issue description) "images which will always cause a problem during `app upgrade` unless workarounds are deployed, especially ones which are used in many recipes?". We have over 200 different docker images used across Co-op Cloud recipes¹ (🤯🤯🤯) and as far as I know Postgres is the only one which causes breaking changes on **every** major version upgrade. Adding a warning for the ~200 other images seems it would create a lot of noise for recipe maintainers, that would like train people into ignoring the actually-critical Postgres ones. The only other semi-related case I think of where a warning might be helpful are recipes like `minio` where we're deliberately holding back a docker image upgrade because there's a specific hellish major version upgrade, or `discourse` where there are some bogus high-numbered tags that don't represent real software versions – but neither of those is a problem with _every_ major image version. ¹`rg -NI --no-heading 'image:' | cut -d':' -f2 | sed -e 's/"//g' -e 's/^[[:space:]]*//' | sort -u`
Author
Owner

Another possible idea, rather than a warning, is adding an abra recipe lint error if a recipe has a image: postgres but isn't using a custom postgres entrypoint? Still filthy but possibly less so.

Another possible idea, rather than a warning, is adding an `abra recipe lint` error if a recipe has a `image: postgres` but isn't using a custom postgres entrypoint? Still filthy but possibly less so.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#597
No description provided.