Ability to debug when things go wrong in a physical cluster

[samyak-jn]

Hi folks, 👋

Is your feature request related to a problem? Please describe.

Is there a way to get logs and errors in one place, I can see some errors like one mentioned below when I am running kcp binary in the foreground but is there a way where I can get errors separately in forms of logs.

E0215 17:48:37.929559  154705 cluster.go:144] error starting syncer in push mode: The following resource types were requested to be synced, but were not found in the KCP logical cluster: [clusterroles.rbac.authorization.k8s.io]
E0215 17:48:37.929651  154705 controller.go:252] "cluster" controller failed to sync "admin#$#k3d-test-kcp-cluster", err: The following resource types were requested to be synced, but were not found in the KCP logical cluster: [clusterroles.rbac.authorization.k8s.io]

Let's take an example of pods as a resource,
I applied a related YAML file for it which is supposed to create a pod. Since I'm using KCP for testing purposes I know that I have connected it to one physical cluster and I can see pod existing from my physical cluster end and the pod (was in Init state) while going through kubectl describe from the physical cluster side I got to know there was a problem with configmaps but there was no entry of POD in kcp side and hence I wasn't able to locate those errors

What I'm proposing for now?
For this issue particularly, I want to fetch all the pod issues occurring in physical clusters. And then later on (if already exists let me know) if we can fetch errors (the reason behind which the resources are not reaching the desired state) in form of logs It will be awesome!

[ncdc]

@samyak-jn I'd like to propose a couple of things:

1. We need 1 issue that specifically covers visibility of things in physical clusters - when something goes wrong and you need to e.g. kubectl describe pod/foo, how can kcp address that?
2. I'd like to make it an explicit non-goal that the initial method of diagnosing a problem is via logs. It's a much better user experience if we can present state to users using the APIs, especially in status.conditions. Logs certainly are valuable, but generally as a 2nd/last resort compared to a nice UX. And also remember that many times, users won't have access to server/controller logs.

Can we use this issue for (1)? Or close it and use #25 instead?

[samyak-jn]

Yes, we can use this issue for 1, that does make more sense!