DB now incompatible because not pinned in docker-compose.yml

[warrenvw]

As reported by @erick on #docker, postgres was not pinned in docker-compose.yml.

https://stackstorm-community.slack.com/archives/C4QEPNE85/p1519237731000487

This lead to the situation where the DB (e.g. postgres) was initialized with what's now an incompatible version.

The simplest solution appears to be pinning each of postgres, mongo, redis and rabbitmq. README.md needs to be updated with information how to resolve any version incompatibilities (changing pinned version as required).

If this is insufficient, then let's discuss below. Why is it insufficient? Do we need to go so far as to document the DB upgrade procedure as it relates to StackStorm?

[arm4b]

I don't think we need to document DB upgrade procedure.
In StackStorm release upgrade notes we just link to respective DB upgrade procedures, stating which version was supported previously and which now, ex: https://docs.stackstorm.com/upgrade_notes.html#st2-v2-4

Talking about the versions pinning. As I see in other files (CI), we only pin MongoDB to 3.4 version: https://github.com/StackStorm/st2-packages/blob/master/docker-compose.override.yml#L49. Hadn't any issues with the other software.

[warrenvw]

In hindsight, what I meant to say was "document the DB upgrade procedure as it relates to st2-docker".

[warrenvw]

While it's true that the version of postgres doesn't matter.. if the major version bumps between the time the data directory was initialized, and the next invocation of docker-compose up (keeping in mind the data volume persists), then it is likely there will be errors as mentioned by @erick. We just need to be sure resolution is documented.

[arm4b]

@warrenvw That makes sense now! 👍

[shusugmt]

I'm still not sure this was the right approach. Usually the original problem reported may happen when:

• The user intentionally run docker pull then it changed the reference of postgres:latest to the one which has a newer major version
• And somehow the postgres container created by the docker-compose.yml restarted

docker-compose may not pull any newer image unless specified to do so, for safety as I understand (You can find related discussion at docker/compose#3574)

The point is, all those are the docker practices, and completely separated from the context of StackStorm or st2-docker. If the stackstorm image itself actually does not need the version pinning for external libraries except mongo as @armab pointed out, I think it is better to leave others latest.