Description
As per our logpipeline and metricpipeline controllers, we currently watch Pods too, with the following implementation:
ownedResourceTypesToWatch := []client.Object{
// ...
&corev1.Pod{},
// ...
}
// ...
for _, resource := range ownedResourceTypesToWatch {
b = b.Watches(
resource,
handler.EnqueueRequestForOwner(mgr.GetClient().Scheme(),
mgr.GetRESTMapper(),
&telemetryv1beta1.LogPipeline{},
),
ctrlbuilder.WithPredicates(predicateutils.OwnedResourceChanged()),
)
}Source: https://github.com/kyma-project/telemetry-manager/blob/main/controllers/telemetry/logpipeline_controller.go
Watching Pods was introduced in #1236 for properly reacting to pod CrashLoops and thus ensuring a more reliable Gateway/Agent Healthy condition check (especially for the rollout process of the manager).
But according to the code snippet above, Pods won't even be watched properly, since EnqueueRequestForOwner only responds to resources owned by the resource type passed in the 3rd argument, which is telemetryv1beta1.LogPipeline in this case, thus no Pods will trigger reconciliation, since no Pods are directly owned by the LogPipeline CR.
Description
As per our logpipeline and metricpipeline controllers, we currently watch Pods too, with the following implementation:
Source: https://github.com/kyma-project/telemetry-manager/blob/main/controllers/telemetry/logpipeline_controller.go
Watching Pods was introduced in #1236 for properly reacting to pod CrashLoops and thus ensuring a more reliable Gateway/Agent Healthy condition check (especially for the rollout process of the manager).
But according to the code snippet above, Pods won't even be watched properly, since
EnqueueRequestForOwneronly responds to resources owned by the resource type passed in the 3rd argument, which istelemetryv1beta1.LogPipelinein this case, thus no Pods will trigger reconciliation, since no Pods are directly owned by the LogPipeline CR.