radically simplify settings needed in ods-configuration/ods-core.env.sample

[clemensutschig]

Is your feature request related to a problem? Please describe. ods-core.env.sample contains a lot of 'unneeded' information

1. host names of OCP routes
2. duplication of information (e.g. no $ substitution)
3. other data that we can easily get out of ocp

This can lead to a wealth of (configuration) errors - that we don't want to have ... and saw in the work for @georgfedermann - edp in a box

Describe the solution you'd like the solution is fourfold

1. The config file should be SUPER simple: perfect world - some attributes need to be filled only: 1.1 bitbucket url 1.2 jira url 1.3 confluence url 1.4 ocp api host

2. All routes' hostnames should be OCP created - and not configured in the env file (https://github.com/opendevstack/ods-core/blob/master/configuration-sample/ods-core.env.sample#L44)

3. Host/Url route combos that that come from OCP should be updated automatically in the ods-core.env within the respective make targets, after the installation of a component. I would expect some sort of amend of ods-core.env on the fly.

4. $ substitutions should work (https://github.com/opendevstack/ods-core/blob/master/configuration-sample/ods-core.env.sample#L43-L47)

Additional context follow up to #517 / @metmajer @michaelsauter - fyi

[michaelsauter]

Please see my comment in https://github.com/opendevstack/ods-core/issues/517#issuecomment-643938058:

sometimes the services might run outside of OpenShift (e.g. one can host Nexus elsewhere). In that case, users need to define where Nexus is, and that information cannot be automatically collected.

What we can do is fill the information in ods-core.env based on the installation, that would work (your point 3).

To (4): The file is a simple env file, no substitutions work there ...

[clemensutschig]

@michaelsauter

sometimes the services might run outside of OpenShift (e.g. one can host Nexus elsewhere). In that case, users need to define where Nexus is, and that information cannot be automatically collected.

we own the file - we know what the defaults are .. (and if they are there) - we can overwrite :) Secondly - what the user calls in the makefile is what we install / update, or?

Here is my view.. every configure.sh should set the routes/host stuff.. similar for any b64 pieces.. - so if you call make '...' - that target will amend your settings ...

[michaelsauter]

Not to our future selfs: I realised one more thing regarding (4) ... besides teaching Tailor substitution, we would also need a solution for all places where we grep for values in ods-core.env and read the values (e.g. during SQ configuration).