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 specified a non-existing tenantID or clientID for accessing AKV, and then used the command kubectl get keymanagementprovider to check the status. The ISSUCCESS was false which was as expected. However, when I described the specific keymanagementprovider resource, the error field included a lengthy call stack, most users don’t need to deal with those messages.
What did you expect to happen?
The error field should include concise and precise messages about error description, the reason and possible mitigation methods.
What version of Kubernetes are you running?
AKS
What version of Ratify are you running?
0-dev (dev.20240505.6163b7e)
Anything else you would like to add?
No response
Are you willing to submit PRs to contribute to this bug fix?
Yes, I am willing to implement it.
The text was updated successfully, but these errors were encountered:
What happened in your environment?
I specified a non-existing tenantID or clientID for accessing AKV, and then used the command
kubectl get keymanagementprovider
to check the status. TheISSUCCESS
wasfalse
which was as expected. However, when I described the specifickeymanagementprovider
resource, the error field included a lengthy call stack, most users don’t need to deal with those messages.What did you expect to happen?
The error field should include concise and precise messages about error description, the reason and possible mitigation methods.
What version of Kubernetes are you running?
AKS
What version of Ratify are you running?
0-dev (dev.20240505.6163b7e)
Anything else you would like to add?
No response
Are you willing to submit PRs to contribute to this bug fix?
The text was updated successfully, but these errors were encountered: