Selective deployment errors not visible in Pod logs

[kate-goldenring]

Say you apply this spin app that has two components hello and goodbye but select that nonexistent component foo is run:

apiVersion: core.spinkube.dev/v1alpha1
kind: SpinApp
metadata:
  name: hello-salutation-spinapp
spec:
  # TODO: change to image hosted at ghcr.io/spinkube/spin-operator/salutations when published
  image: "ghcr.io/kate-goldenring/spin-operator/examples/spin-salutations:20241022-144454"
  replicas: 1
  executor: containerd-shim-spin
  # Configure the application to only contain the "hello" component
  components: ["foo"]

The pod with Error with no logs. You have to look at the containerd logs to find that an improper component was selected:

time="2024-11-07T06:09:43.569108376Z" level=error msg="run_wasi ERROR >>>  failed: Specified component "foo" not found in application"

time="2024-11-07T06:09:43.569570479Z" level=info msg="error running start function: Specified component "foo" not found in application"

Could we somehow surface this in the Pod logs?

[jsturtevant]

I think the shim related stuff really shouldn't be in the pod logs but it would be possible to get them surface by moving the stio.redirect() before any logs that you want redirected.

This sort of relates to containerd/runwasi#619

Something like this should really be surfaced up to Kubernetes as an event IMO, sort of like when not pulling fails. I don't know if it is possible to pass this info up through cri though.

[kate-goldenring]

I 100% agree this should be surfaced as a K8s event. We also don't surface things like precompilation failing as K8s events. That would maybe be a good first one to target because runwasi could define a strategy for surfacing it. In the mean time, it may make sense to surface this error. I put up a PR for that: #229