Add a warning about bumping postgres versions during abra recipe upgrade
#597
Open
opened 2024-03-30 15:18:23 +00:00 by 3wordchant
·
10 comments
Labels
Clear labels
abra
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
design
documentation
duplicate
enhancement
fedi
fedi-infra
finance
funding
good first issue
help wanted
installer
legal
performance
proposal
question
security
test
wontfix
Everything to do with abra
Ping/pong on comms
Something is not working
Go build related issues
Getting the robots into the mix
Opening this thing up
Contributors stuff
Our main website
Design thinking required
Let's write things together
This issue or pull request already exists
New feature
Democratic decision making
Money things
Anything related to grant funding
Easy start with development
Need some help
Installation related issues
Performance related
Large change which requires feedback & decisin making
More information is needed
Securing our shit
Unit or integration test suite
This won't be fixed
No labels
enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
3wordchant
aadil (Aadil Ayub)
abra-bot (Abra Bot)
ammaratef45
amras (Sarma)
Apfelwurm
BornDeleuze
Brooke
carla
cas (Cassowary)
coopcloud
cyrnel
decentral1se (d1)
dede
devydave
fauno (fauno)
iexos
jade (Jade Ambrose)
jjsfunhouse
jmakdah2 (Jackie Makdah)
joe-irving (Joe Irving)
kawaiipunk (KawaiiPunk)
knoflook
kolaente
lambdabundesverband
linnealovespie (April)
moosemower
moritz
notplants
oxaliq (sorrel)
p4u1
pharaohgraphy (Andrew 🐦🔥❤️🔥✴️)
renovate-bot (Comrade Renovate Bot)
ripclap
simon
sixsmith (Sixsmith)
stevensting
trav (Trav Fryer)
val (val (he/him))
yksflip
Clear assignees
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/organising#597
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Accepting a Postgres major version upgrade during
abra recipe upgradecauses 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 upgradeunless workarounds are deployed, especially ones which are used in many recipes?CC @kawaiipunk
Isn't this just one for the recipe release notes where you can load in your own scary warning?
@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 runningabra recipe release… ways to make both of those more likely could help of course!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 upgradeit 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
Proposal: add additional INFO level logging for the type of upgrade
abradiscovers inabra 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
MAJORupgrade" 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.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:
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.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.
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.
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...
Likewise thanks for thoughts!
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 upgradeunless 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
miniowhere we're deliberately holding back a docker image upgrade because there's a specific hellish major version upgrade, ordiscoursewhere 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 -uAnother possible idea, rather than a warning, is adding an
abra recipe linterror if a recipe has aimage: postgresbut isn't using a custom postgres entrypoint? Still filthy but possibly less so.Not a solution but an additional helping feature was added: toolshed/abra#611
When choosing the upgrade bump type, you can see again that a dangerous upgrade might be happening.