-
Notifications
You must be signed in to change notification settings - Fork 44
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
Bump nova-api probe timeout #381
Bump nova-api probe timeout #381
Conversation
In tempest we saw that a longer nova API request from tempest can block the pod probes resulting in a pod restart. So this patch bumps the timeout values of the probes to see if it mitigates the issue or not.
Skipping CI for Draft Pull Request. |
/test-all |
/test-all |
/test all |
/retest all |
@gibizer: The
The following commands are available to trigger optional jobs:
Use In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/test nova-operator-build-deploy-tempest |
/test nova-operator-build-deploy-tempest tempest failed but that is actually a tempest issue. I try to fix that in https://review.opendev.org/c/openstack/tempest/+/883892 but if the test_list_all_networks runs early when no network is created yet by other test cases then it will fail. So we should probably skiplist this test. No nova-api container restart was observed during the run so I considers this tempest run a success from this PR perspective. I also noticed that currently tempest is run with parallelism of 15. This is will not work later when we enable scenario tests. |
/test nova-operator-build-deploy-tempest |
/test nova-operator-build-deploy-tempest I don't see what is failed in the deploy side of the job. But we don't reach the tempest step. So this is not a tempest failure |
4/4 success |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks gibi, lets proceed with this for now and see if the ci stablises.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gibizer, SeanMooney The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
when deploying locally in crc glance can crashloop indefintly because the readiness and liveness probe were set to strictly. The nova-operator relaxed the probes becuase of tempest failures in openstack-k8s-operators/nova-operator#381 This change updates the glance values to match.
When deploying locally in crc keystone can crashloop indefintly because the readiness and liveness probe were set to strictly. The nova-operator relaxed the probes becuase of tempest failures in openstack-k8s-operators/nova-operator#381 This change updates the keystone values to match.
When deploying locally in crc placement can crashloop indefintly because the readiness and liveness probe were set to strictly. The nova-operator relaxed the probes becuase of tempest failures in openstack-k8s-operators/nova-operator#381 This change updates the placement values to match.
When deploying locally in crc placement can crashloop indefintly because the readiness and liveness probe were set to strictly. The nova-operator relaxed the probes becuase of tempest failures in openstack-k8s-operators/nova-operator#381 This change updates the placement values to match.
when deploying locally in crc glance can crashloop indefintly because the readiness and liveness probe were set to strictly. The nova-operator relaxed the probes becuase of tempest failures in openstack-k8s-operators/nova-operator#381 This change updates the glance values to match.
In tempest we saw[1] that a longer nova API request from tempest can block the pod probes resulting in a pod restart. So this patch bumps the timeout values of the probes to see if it mitigates the issue or not.
[1] #377 (comment)