Do not assume insecure ssl communication with the naive logcache implementation

[georgethebeatle]

Background

Today the naive logcache implementation of Korifi lives alongside all other CF v3 API handlers. This is confusing as the logcache endpoints are not a part of the CF API. With the most recent developments around using logcache for fetching not only logs, but also metrics, things become slightly more involved.

On the one hand the cf cli needs to be able to reach the logcahe from outside of the cluster (via ingress). On the other, the CF v3 implementation needs to be able to reach the same api endpoint from the inside. This is not a problem for real clusters, but it is a challenge on kind, where the ingress essentially resolves to localhost.

Action to take

• Explore the possibilities of hitting the same url both from the outside and from the inside.
  • We could exploit the knowledge that the logcache runs on the same host as the CF v3, but this means its certificate will have to be valid both for the ingress and the internal dns service
  • Use the "kind" docker network hostname for internal communication. This might be problematic on mac, since docker is running in a VM and not directly on the host.
  • Do something else

[georgethebeatle]

Insecure loopback to localhost is only needed for the kind dev experience. Therefore we do not need to default to localhost here, but rather make the deploy-on-kind.sh and installer scripts to pass the correct helm values

• Enable external log cache
• Skip ssl
• In the helm chart defult the log cache url to :<internal-port>

This way we simplify the code and achieve the defaulting in the helm chart.