fix Grafana access

[akihikokuroda]

Summary

fix #534

Details and comments

Commented out the keycloak integration in the values.yaml file. It can enable back by uncomments the lines and put the local ip address in a few lines.

[psschwei]

Why this change? (if we wanted to expose the service, I think it'd be better to do it via ingress rather than directly exposing the node...)

[akihikokuroda]

The service must be exposed for the sign-in of the Grafana with Keycloak. It is disabled by default so I can remove this and add additional comment lines below. It's a little tricky to put the keycloak behind the ingress and use with OpenId connect so the node port is the easiest way for now. I'll try the ingress configuration in an separate issue.

[psschwei]

Given all the issues we've run into in this space, the more I think about it, the more trying to supply a monitoring stack for users to install seems like a non-ideal use of our time. What I mean by that is, almost everyone who would think about running quantum-serverless is going to already have an existing setup, and you'd expect them to have a monitoring stack as part of that setup (whether they're rolling their own Promethues/Grafana or, more likely, using services from their cloud provider). So why are we fighting through all these issues for something very few people, if any, are likely to use? The metrics generation and the actual dashboards we should absolutely keep, but the installation of Prometheus / Grafana / Loki / etc. I think you could make a major case for dropping from the helm chart...

[akihikokuroda]

Users have different environments so we can not cover all cases. It may be better to define and prioritize the environments for us. All components in the helm chart have the enable(d) switch so we can disable some of them and put comments explaining when it should be enabled.