Hardcode operating mode env variable

[hectorj2f]

We had problems with the deployments due to a wrong value in the OPERATING_MODE en variable. So we decided to hardcode to avoid issues with out-of-date config maps. Moreover, we're not able to change the value of config maps in an automatized manner.

[sbose78]

Moreover, we're not able to change the value of config maps in an automatized manner.

Oh, why is this? Can't this be a deployment config triggered change(somehow)?

[alexeykazakov]

We also need to use "clustered" be default.

[alexeykazakov]

And btw. Do you think it's a better way to handle it? Maybe still keeping this in the configmap template in our repo and just remove it from the configmap in OS (if it's feasible to support configmaps merging on the OS side cc: @jfchevrette @vpavlin) is better?

[hectorj2f]

@alexeykazakov the best way is to let the owners of the application to manage the properties that are passed as arguments. That isn't possible unless we hardcode all the properties. Regarding the secrets, we could also manage them by using third party (vault, gpg keys, ...). However I understand the situation at this moment.

[vpavlin]

As long as this is not something that will change across environments (i.e. stage non-clustered, prod clustered) I am fine with this approach and I think it's appropriate solution for this particular problem.

Rule of thumb here is - if you are 100 % sure this value will be same across all the envs (local, stage, prod, hybrid-cloud-of-your-dreams) then feel free to hardcode it. Otherwise, use configMaps

[alexeykazakov]

The ideal requirements are the following:

1. It should be possible to configure the clustered/standalone mode depending on env (both Cluster mode and the number of replicas bc it will fail if there is more then 1 replica in standalone mode)
2. There should be the default values (clustered mode + 3 replicas). If the env vars is not set in particular environment then the default ones are used.
3. Devs should be able to change the default values.

Can we achieve all of this if we keep the default values in our template but just don't specify them in the OSIO OSD environments. But if needed we can override them in any environment/cluster we want (with the SD team help)?

If it can take some time to meet all the requirements we can merge this PR for now because it's better than we have now and create separate issues to improve it.

[alexeykazakov]

I'm approving because it's better then relaying on the configmaps devs can't control but we need to evaluate all options to achieve requirements above (we can do it in separate issues)

[hectorj2f]

@alexeykazakov

It should be possible to configure the clustered/standalone mode depending on env (both Cluster mode and the number of replicas bc it will fail if there is more then 1 replica in standalone mode)

Whatever is pushed to prod-preview, it would be released in production. Therefore we can only have one environment, consequently a template.

There should be the default values (clustered mode + 3 replicas). If the env vars is not set in particular environment then the default ones are used.

Yeah! we experienced that before, we need more than one replica if we set KC to clustered mode.

Devs should be able to change the default values.

Yeah, we should be able to do changes with some limitations.

[alexeykazakov]

Whatever is pushed to prod-preview, it would be released in production. Therefore we can only have one environment, consequently a template.

Probably true for preview vs prod. But we could have other envs. Appsec or some on premise or local cluster which would be nice to control via configmap.

Yeah! we experienced that before, we need more than one replica if we set KC to clustered mode.

Yep. At least 3 replicas for cluster mode and the only one for standalone. Otherwise KC will fail.

[sbose78]

We might have situations where we would need to run production in one mode and staging in another.

Example, if there's an issue with clustered mode, we might want to temporarily set production to standalone mode while we debug staging in clustered mode.

So in that case , workflow should be

1. Deploy standalone in both ( using the proposed way here in this PR )
2. Manually change staging to clustered mode and proceed with the debugging?

[alexeykazakov]

I created a new issue to follow up - fabric8-services/fabric8-auth#45