You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some changes to resources that the ingress-controller/operator watches(ngrok CRs, ingress, service, gateway, etc), we don't always create events that shows what the controller is doing.
For example, when running kubectl scale deployment ngrok-ascii --replicas=<N>, the kubernetes deployment controller will log events for scaling the deployment as an example:
The replicaset controller will also create events as well as part of this scaling action:
It also very common for pod issues to be reported as events such as readiness or liveness probes failing. This helps users debug issues without having to go diving through all of the controller logs.
For instance, when creating an Ingress resource with ingressClassName: ngrok, if I describe it with kubectl describe ingress my-ingress, there won't be any events.
Use Case
The use case for this is to make it easier to see what is happening inside of the controller without having to dive into the logs for simple issues. For resources that create ngrok CRs(service, ingress, gateway), we should create events that bubble up any issues or state change in the particular resource or the CRs to make it easier for end users.
Related issues
No response
The text was updated successfully, but these errors were encountered:
Description
For some changes to resources that the ingress-controller/operator watches(ngrok CRs, ingress, service, gateway, etc), we don't always create events that shows what the controller is doing.
For example, when running
kubectl scale deployment ngrok-ascii --replicas=<N>
, the kubernetes deployment controller will log events for scaling the deployment as an example:The replicaset controller will also create events as well as part of this scaling action:
It also very common for pod issues to be reported as events such as readiness or liveness probes failing. This helps users debug issues without having to go diving through all of the controller logs.
For instance, when creating an
Ingress
resource withingressClassName: ngrok
, if I describe it withkubectl describe ingress my-ingress
, there won't be any events.Use Case
The use case for this is to make it easier to see what is happening inside of the controller without having to dive into the logs for simple issues. For resources that create ngrok CRs(service, ingress, gateway), we should create events that bubble up any issues or state change in the particular resource or the CRs to make it easier for end users.
Related issues
No response
The text was updated successfully, but these errors were encountered: