-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
provider status endpoint: hurricane provider reports excessively large amount of available CPUs #232
Comments
The
|
Checked with Max C., they said they are deploying the updates through the Console. Dockerfile Interestingly, while I'm seeing few more new |
Have attempted to reproduce excessively high CPU count stats associated with issue 232 across several test cluster builds. The issue is difficult to replicate due to:
Based on these difficulties in intentionally provoking the issue on a test provider - would suggest that we wait for the Hurricane provider and/or other provider (OCL owned preferably) to encounter this issue naturally, leave provider in that state during which time only new bidding may be affected, and troubleshoot further on such a provider. It's interesting that the only pods in state ContainerStatusUnknown are console stat pods. Believe the most likely cause of such a state is a scenario such as: rolling update is provoked > updated pod spawned > Kubernetes attempts to delete the original pod post update > pod is already deleted from containerd for some reason > K8s reports ContainerStatusUnknown as it cannot determine the state of a pod not present in the container runtime. But have attempted multiple deployments of the console stats app on test providers > provoked updates to the deployment > and no such issues. To my knowledge these deployments are the sole contributor to the ContainerStatusUnknown status pods. The stats deployment also have many Completed status pods. |
this has just occurred again on the Hurricane provider and below are the steps I've taken to patch it (but not a permanent fix):
|
hurricane provider reports excessively large amount of available CPUs
Versions
Logs
I've tried restarting the operator-inventory which previously used to "fix" this issue, but to no avail this time.
The text was updated successfully, but these errors were encountered: