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
I configured the cosign verifier with non-existing keymanagementprovider resource, the command kubectl get verifier cosign-verifier indicated a success. However, when I started to deploy an image, the deployment failed as expected. The Ratify log showed the keymanagementprovider resource did not exist.
Anything else you would like to add?
Is it feasible to proactively notify users about configuration issues? In real-world scenarios, typos or other configuration errors can occur. For instance, when users run kubectl get verifier to check the status, everything might appear fine initially. However, these configuration issues may only surface during image deployment. In large-scale deployments, multiple error logs related to the same configuration issue can accumulate, which could be better avoided to conserve cluster resources.
Are you willing to submit PRs to contribute to this feature?
Yes, I am willing to implement it.
The text was updated successfully, but these errors were encountered:
What would you like to be added?
I configured the cosign verifier with non-existing keymanagementprovider resource, the command
kubectl get verifier cosign-verifier
indicated a success. However, when I started to deploy an image, the deployment failed as expected. The Ratify log showed the keymanagementprovider resource did not exist.Anything else you would like to add?
Is it feasible to proactively notify users about configuration issues? In real-world scenarios, typos or other configuration errors can occur. For instance, when users run
kubectl get verifier
to check the status, everything might appear fine initially. However, these configuration issues may only surface during image deployment. In large-scale deployments, multiple error logs related to the same configuration issue can accumulate, which could be better avoided to conserve cluster resources.Are you willing to submit PRs to contribute to this feature?
The text was updated successfully, but these errors were encountered: