Documentation to upgrade very old version (3.1) to newest
Nobody has claimed this yet.
- Dominant language
- Mustache
- Stars
- 197
- Forks
- 104
- Avg merge
- 22m
- Merged PRs (30d)
- 2
Description
I didn't found the discussion section, so I ask it as an issue. Sorry if it's not the right place.
I deployed mastodon (techlover.eu) a long time ago with the helm chart.
helm -n mastodon list
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
mastodon mastodon 10 2021-07-12 14:18:44.565497611 +0200 CEST deployed mastodon-0.1.0 3.1.5
I want to migrate version to the latest (even if I need to pass to 4.x then 5.x...)
There are many risks, even if I did database backups, I really don't know the procedure excepting getting the chart and try to upgrade.
Old helm charts points on removed dependencies, so it could be very difficult to fix a failed upgrade.
- is there something to do to "dump" the current instance and "import" if something goes wrong (I mean, if I need to completely remove the instance to install the last one)
- is there any chance to find out the 4.X version and to do the update?
- Something weird: I remember that I did a PR, years ago, to fix something (https://github.com/mastodon/mastodon/pull/15072). So the helm chart I used is not those on this repository. :(
A solution that I wanted to do is to install a new version in another namespace, and to have a data transfer from the old instance... any way to do this?
I'm afraid to lose everything.
(Yes, I should have updated more often, but I've had a busy life with a baby, an illness, and a lot of work...)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the existing Helm chart history and the reported Mastodon 3.1.5 deployment context first. Determine whether a supported upgrade path, backup and restore procedure, or migration between namespaces can be documented, including any version-by-version constraints and removed dependencies. Done means the upgrade guidance is tested or clearly scoped and covers recovery options.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- helm, kubernetes
- Domain
- devops, documentation, infrastructure
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100