Fallback to db-single flag with default disable about build-deploy-tool

[shreddedbacon]

Yep, I'm proposing failure is the default

[tobybellwood]

I agree that a fallback default is a bad thing:tm: , and should only really be enabled at a cluster level (to account for a missing dbaas). If a project, or branch, wants a single - they can define it in their docker-compose - I don't think we need a complex triple override system?

[shreddedbacon]

With work I'm doing on the dbaas-provider configuration in this tool, and looking at past experiences in platform with builds that fail to provision against a dbaas for any number of reasons (requested environment type doesn't have a provider, the dbaas-operator is not responding/not installed), a build failure would have been much better and caused less issues for fixing it after the fact.

I know that we do have some users that WANT db-single pods, and they've already accounted for these in their docker-compose files or lagoon.yml as overrides, this behaviour wouldn't change.

[seanhamlin]

Perhaps fail should be the default, and only if there is some positive action by the user (e.g. what you have above) then it should continue with a pod. Agree, this for larger clusters is a pain.

[shreddedbacon]

@tobybellwood would be good to get some thoughts on this, so I can potentially roll this into #115

[shreddedbacon]

bump @tobybellwood