Kubernetes errors aren't surfaced by Juju

[Kenneth Koski]

I am working on a charm, and ran into a situation where the workload pod wouldn't come up due to an error on my part that I fixed. However, it would be really useful for Juju to surface errors like this, so that charm authors don't have to poke around in the Kubernetes infrastructure to figure out what went wrong.

The particular error in this case was shown by `kubectl describe -nkubeflow replicasets`, which showed these events:

Events:
  Type Reason Age From Message
  ---- ------ ---- ---- -------
  Warning FailedCreate 10m (x19 over 32m) replicaset-controller Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-pilot.kubeflow.svc:15017/inject?timeout=30s: dial tcp 10.152.183.118:15017: connect: connection refused

`juju status` on the other hand, just showed this:

istio-pilot/0* waiting idle waiting for container

It would be nice if `juju status` could at least show something like this:

istio-pilot/0* waiting error ReplicaSet error, see replicasets/istio-pilot-6b9c46cbfd for more info

[Pen Gale (pengale)]

In general, I think that Juju wants to abstract the underlying cloud details away from an operator.

But I think this falls under the general umbrella of making it easier to debug charms, possibly with an additional level of logging and messaging beyond what we'd ordinarily display.

Added a "charm-debugging" tag so that we can find this, and also added to the wishlist.

[Cory Johns (johnsca)]

Possibly this doesn't apply when using the sidecar approach. For the external operator approach, I believe there was already discussion about having K8s events surfaced to the charm in some fashion which would likely allow the charm to surface the relevant info to Juju status.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.