Can't find migration version 128 about docker.official.image HOT 9 CLOSED

@azgul we had a problem were our CI deployed our 0.66.0-rc.1 as the latest version, this happened for a few minutes and we removed the latest from our registry then we rebuild the correct latest version. You may dowloaded the latest in the middle of that process.

We are sorry about that problem. There are 2 ways to solve, one is accessing your database and at the collection migrations edit the only record you will see and set the field version to 121.

The second option is exactly what you did, keep using the release candidate version, we are about to release the final version and will be available as 0.66.0 in a few hours.

That problem should not happen again, was caused by a step where we was updating how we deploy the images to docker hub.

I'll close this issue, please reopen it or let me know if you still have problems.

Thanks.

from docker.official.image.

yeah.. luckily you went to a release-candidate so the chances of db-change are minimal, but still.

Anyway this prompted me to have another look at my continuous integration solution. I also use Watchtower. In addition to my previous comment, I also found this pull-request: containrrr/watchtower#197. I am going to try to combine this functionality with some kind of incremental backup technology (e.g. something like http://www.admin-magazine.com/Articles/Using-rsync-for-Backups/(offset)/2 ). Then I can create a backup of the database before running the new version; which should allow easy downgrades in case something breaks again.

I'll post my script here if everything works and you're interested.

from docker.official.image.

So my rocket.chat instance is working agian.

I created a new rocketchat instance, and logged into the mongo-database to find its current migration level.

docker-compose exec mongo /bin/bash
root@373da192e035:/# mongo
MongoDB shell version: 3.2.20
connecting to: test
rs0:PRIMARY> use rocketchat
switched to db rocketchat
rs0:PRIMARY> db.migrations.find()
{ "_id" : "control", "version" : 121, "locked" : false, "lockedAt" : ISODate("2018-06-25T09:34:59.270Z"), "buildAt" : "2018-06-16T21:33:15.003Z" }

I then changed the migration-level of the broken rocketchat instance to 121:

 docker-compose exec mongo /bin/bash
mongo
rs0:PRIMARY> use rocketchat
switched to db rocketchat
drs0:PRIMARY>db.migrations.find()
{ "_id" : "control", "version" : 128, "locked" : true, "lockedAt" : ISODate("2018-06-21T21:24:50.824Z"), "buildAt" : "2018-06-16T21:33:15.003Z" }
rs0:PRIMARY> db.migrations.update({"_id": "control"}, {"version": 121, "locked": false})
WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
rs0:PRIMARY> db.migrations.find()
{ "_id" : "control", "version" : 121, "locked" : false }
exit
exit
docker-compose restart

Watch the logs, and it said {"line":"160","file":"rocketchat_migrations.js","message":"Migrations: Not migrating, already at version 121","time":{"$date":1529919716358},"level":"info"}.

Now running: Rocket.Chat Version: 0.65.2 ~~ SAML login is still broken lol but at least existing sessions work again.

from docker.official.image.

I set the image version to image: rocketchat/rocket.chat:0.66.0-rc.1 and voila:

{"line":"160","file":"rocketchat_migrations.js","message":"Migrations: Not migrating, already at version 128","time":{"$date":1529777900735},"level":"info"}
Using GridFS for custom sounds storage
Using GridFS for custom emoji storage
ufs: temp directory created at "/tmp/ufs"
Updating process.env.MAIL_URL
➔ System ➔ startup
➔ +----------------------------------------------------+
➔ |                   SERVER RUNNING                   |
➔ +----------------------------------------------------+
➔ |                                                    |
➔ |  Rocket.Chat Version: 0.66.0-rc.1                  |
➔ |       NodeJS Version: 8.9.3 - x64                  |
➔ |             Platform: linux                        |
➔ |         Process Port: 3000                         |
➔ |             Site URL: <snip>                       |
➔ |     ReplicaSet OpLog: Enabled                      |
➔ |          Commit Hash: b86c9333f6                   |
➔ |        Commit Branch: HEAD                         |
➔ |                                                    |
➔ +----------------------------------------------------+

I can only speculate, but perhaps :latest was updated twice. First to the release candidate then back to latest release (0.65.2?), effectively breaking the installs of everyone who auto updated.

from docker.official.image.

Hi @azgul its a risky fix you took; if there are DB changes between 0.66.0-RC.1 and 0.66.0-final then you won't get them.

It seems they inadvertently pushed an update which updated the required db-level for the app, but did not include the migrations. So it should be possible to update the database to lower the required db-level. The migration collection in MongoDB to be precise. But I don't know what to set it to. It would have been nice to have some kind of official response from one of the devs, but alas.

The final release is due this Wednesday Final Release - On the 27th.

Azgul, were you using https://hub.docker.com/r/rocketchat/rocket.chat/ or https://hub.docker.com/_/rocket.chat ?

I am no longer going to use their images directly; instead I will use my private Docker repository to rebuild their Dockerfile once a week.. Should minimize the changes of it breaking due to their accidental pushes..

from docker.official.image.

@ChessSpider Well, that doesn't sound good. I can't tell for certain what I was using, but only what I am using now. As I didn't commit my changes to docker-compose.yml.

It seems they inadvertently pushed an update which updated the required db-level for the app, but did not include the migrations.

Interesting theory. I'll await some sort of official response and stick to rc1 until then.

from docker.official.image.

Oh, and additionally, it seems the images from https://hub.docker.com/_/rocket.chat may be a more stable option. E.g. they do not even include dev or rc candidates on that repository so hopefully mistakes like these are more harder to make.

Before, I was on https://hub.docker.com/r/rocketchat/rocket.chat/

from docker.official.image.

Good point - I must've been on rocketchat/rocket.chat the entire time then.

from docker.official.image.

Hi I am having this Expection and i tried above Options but No Use Any Let me Know How to resolve
this Issue " Exception in callback of async function: Error: [Can't find migration version 137]".

from docker.official.image.