Revert "Pin postgres, redis and rabbitmq"

[warrenvw]

Reverts #107

[bigmstone]

This feels like a suboptimal PR. I may have missed part of the conversation here but I'm not sure why we're cool with core platform dependencies changing underneath us without explicitly moving to a new version. We wouldn't do this with library dependencies and I don't see this as any different. I've also been bitten by similar things in the past. Specifically not pinning mariadb version and the API changing slightly.

[arm4b]

@bigmstone See @shusugmt point #106 (comment) for more complete context.

Having said that, we pin now only Mongo to 3.4, - this conforms with behavior in official installation scripts.

[bigmstone]

Yes. I saw that comment on the previous PR and thought to mention this there. I am not sure how I feel about us not pinning at least major versions in ST2 installer as well. We pin mongo for the same reasons we should be pinning other external dependencies. I get it. SQL and AMQP don't change much I'm 2018 but the issue that bit us with Maria was a bug.

I'm just always a fan of the same code running in every installation. I know compose won't upgrade on you but new installations will pull in latest. I'm open to having my mind changed here but the other arguments don't convince me yet.

[shusugmt]

As far as I understand, what we provide in this st2-docker repository is just for starter kit, and not really meant to be usable for any production without modification (except the built image that users can get from dockerhub). docker-compose.yml is also just an example. It will do the job, but can't be used in any production as-is in most cases.

I'm just always a fan of the same code running in every installation

I agree with this. But whether to pin the version is up to the user. And I think this should be controlled by them.

[bigmstone]

As far as I understand, what we provide in this st2-docker repository is just for starter kit, and not really meant to be usable for any production without modification

Like all things that get released this is of variable truth. Some people run this in prod. Even if not though it's a lot of people's first view into ST2 and we're responsible for its quality.

I agree with this. But whether to pin the version is up to the user. And I think this should be controlled by them

Yes - and we're responsible for sane defaults that are tested. The user can modify from there.

[shusugmt]

we're responsible for sane defaults that are tested

The question is, to what extent should we care? I strongly recommend users to pin the image using sha hash especially in production environment to ensure the 100% consistency. If the policy here is to provide quality that covers any environment, then I insist we should do that. But now I think that is too much.

Also, those are the general things in container world, not specific to st2-docker. Users need to learn and decide what to do.

[jeking3]

I think it's best to lock in versions folks know work okay, and roll them forward. I assume part of the goal of this repsoitory is to provide a successful first experience with the product. To that end, locking in the versions is a better choice than allowing them to change and potentially breaking that first experience. This repository helped me get up and running very quickly. If it was DOA, that would have really soured the first experience.