Open chrischdi opened 1 year ago
Example: storage class query took 20 mins to answer.
sorry for the delay here folks, my bad, got dragged into other problems.
The issue here is, during a cluster reconciliation, I've seen a huge time between "cloning" and "powering on the node".
Debugging, I've reached the place where CAPV was waiting for some vCenter answer, at this line.
I don't know yet, on vCenter side why this query is taking some time (and I have reached also the right team to look at it), but this command should have probably timed out first, and this is what @chrischdi is reporting here.
I think this issue is about more than just this specific case. We were wondering in general if we are setting timeouts on govmomi. So we're not getting stuck indefinitely if a request doesn't return.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/remove-lifecycle rotten
/reopen
@sbueringer: Reopened this issue.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/kind bug
What steps did you take and what happened: [A clear and concise description of what the bug is.]
Recent reports did show that a request to vcenter could take forever without timing out. Reason for that is that there seem to be no timeouts set on the reuqests.
Q: is CAPV waiting indefinitely for responses of requests to vCenter?
If it is so, we might want to take action and pass through contexts which include a timeout.
What did you expect to happen:
Requests getting canceled after some time.
Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
Environment:
kubectl version
):/etc/os-release
):