Use properties che.api.{external,internal} if exist.

[monaka]

Signed-off-by: Masaki Muranaka [email protected]

What does this PR do?

Uses properties che.api.external instead of che.api. che.api.internal also.

Che-Theia uses the environment variable CHE_API_INTERNAL to avoid authentication issues reduce network traffic on the multi-user envs.
But che-host doesn't care che.api.internal.

What issues does this PR fix or reference?

None.

[che-bot]

Can one of the admins verify this patch?

[che-bot]

Can one of the admins verify this patch?

[musienko-maxim]

Can one of the admins verify this PR?

[l0rd]

@monaka can you provide more information about what problem you are trying to solve with this PR?

As you should know we are currently limiting the PRs that get merged to master branch to stabilize the code base for the release of 7.0.0 #13637.

[monaka]

@l0rd I noticed when I tracking the another issue on Che-Theia.
And after sending this PR, I rethink this is not the root cause of the issue.

I believe this PR is effective to reduce the workload of Ingress.
So it should be applied to the master. But not urgent. Enough even if after 7.0.0 released.

[skabashnyuk]

che.api.{external,internal} was used mainly in docker. Especially on mac, there was a no chance to use external URL from inside of containers. I'm not sure the in k8s world right now external, internal urls are different.

[monaka]

@skabashnyuk In strict, it should be decided by metrics. But roughly, always accessing ingress gateway is redundant and will cause heavy load to the ingress. I think it's better to access by internal address if we can get the address with low cost.

[l0rd]

Removing label do-not-merge/hold. @monaka can you rebase please?

[amisevsk]

I don't see any documentation about che.api.internal and che.api.external in the current repo; Che will pick up any env vars starting with CHE and convert them to properties, but I don't think we should use properties that don't have defaults (even if null) in che.properties/multiuser.properties.

I do agree that it would be good for Che to use service addresses instead of public-facing routes when possible though.

[monaka]

@l0rd I rebased this and added the 7.x milestone tag. As it is not critical.

[monaka]

I reject this my myself as this PR will be replaced with the another PR soon.