-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The database migrations bug #5198
Comments
i'm thinking along the lines:
so:
|
@udochrist I agree on most of that apart from this. Docker container should be stateless and more importantly immutable. We should be shipping with the software fully installed. To use medusa on any version you should be able to just update the container and the migrations needed would run on start. |
My reasoning here is:
If the container is immutable then there is no need vor any version mgmt and Info to the user.
Me being a new version junkie wants to update ASAP and not wait an additional day until the image gets updated to the new Medusa version by a thirdparty maintainer.
… Am 14.09.2018 um 12:40 schrieb Alexis Tyler ***@***.***>:
a fresh created container always installs or updates medusa. medusa should not be part of the image but installed if its not there.
@udochrist I agree on most of that apart from this. Docker container should be stateless and more importantly immutable. We should be shipping with the software fully installed. To use medusa on any version you should be able to just update the container and the migrations needed would run on start.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@udochrist we provide an official container that's built for master and develop branches on merge. It usually takes about 5 minutes for the new images to be pushed. Edit: Here you are. |
It shouldnt be any more difficult then having a proper 'universal' method of checking if medusa is run in docker. And disable the autoupdating when detected? Updating the docker image will then upgrade the db on next start? Or am i missing something? |
That should be the indicator to check for running inside docker currently. |
Yeah but i don't know if the medusa user will always have access to that. Isn't there something like an env variable? |
@p0psicles https://stackoverflow.com/questions/43878953/how-does-one-detect-if-one-is-running-within-a-docker-container-within-python @udochrist that file doesn't exist 100% of the time. It shouldn't be relied on. |
@OmgImAlexis what do you mean with "... not 100% of the time"? docker-ce/components/engine/daemon/initlayer/setup_unix.go |
@udochrist off the top of my head look at this and this; Things get removed all the time. It'd also make sense not just to fix this for docker but any container runtime it's run in for example running it under lxc. |
For reference, a log of pymedusa/medusa:develop updating.
|
The bug
During the past 2 database migrations, the databases of some of the users got updated past the "max" database version and some got incorrect values inserted into them.
For example, between
v0.2.4
andv0.2.5
we bumped the main DB version from44.9
to44.11
.However, during the migration to shift the quality values, some of the users got incorrect values inserted into the databases.
In addition, some users database versions actually got bumped past
44.11
, to44.12
, which caused an issue for users when the next database migration landed onv0.2.9
.What happens when Medusa updates?
Currently, after Medusa updates its code either using
git pull
or downloading the archive from GitHub, it stops the web server and other threads, closes open files, etc.After that's done, and unless the user had enabled the
No Restart
option, it spawns a new process of Medusa with the same arguments as the one that was running. (source code)How does the restart process affect the database migrations?
Due to the use of process monitors or service restarters, which automatically restart a process if it dies, in-conjunction-with Medusa's restart process (with
No Restart
off),Medusa is being loaded twice, at the same time, by two separate processes.
The database migrations (try to) execute on both processes at the same time, and in doing so, causing unexpected changes to database entries.
The current Docker configuration (ours, @linuxserver's and possibly others) uses
S6 overlay
to automatically restart the server inside the container when it dies (source code).This means that as soon as the original Medusa process dies out,
S6
spawns a new one, but Medusa does too, which causes the scenario explained above.This can be clearly seen in the Docker logs, if you restart Medusa from the web UI, you can see duplicate log messages being logged, and the server tries to bind to the port twice - one of the processes worked, and the other says it can't bind to the port because it's in use, and exits.
It's very possible any other platform that uses a service restarter may have this problem as well.
The Windows installation could also be affected.
What can be done (incomplete)
watchtower
to monitor the Docker container's status and update it to a newer version when one is available.We need to be able to conditionally disable updating and checking out branches, but still have the version checking, to notify users of a new version on the web UI in case they don't want to automatically update.
Additional information
The text was updated successfully, but these errors were encountered: