Skip to content
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

Call stacks were included in the error of keymanagementprovider resource #1450

Open
1 task
yizha1 opened this issue May 7, 2024 · 2 comments
Open
1 task
Assignees
Labels
bug Something isn't working
Milestone

Comments

@yizha1
Copy link
Collaborator

yizha1 commented May 7, 2024

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. 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.
@yizha1 yizha1 added bug Something isn't working triage Needs investigation labels May 7, 2024
@akashsinghal akashsinghal self-assigned this May 13, 2024
@susanshi
Copy link
Collaborator

HI @yizha1 , would you be able to include the customer scenario and detailed error log? thanks

@susanshi susanshi added this to the v1.3.0 milestone Jun 18, 2024
@susanshi susanshi removed the triage Needs investigation label Jun 18, 2024
@yizha1
Copy link
Collaborator Author

yizha1 commented Jun 19, 2024

@susanshi It seems that I did not save the original log, so I cannot provide it. But it is easy to reproduce, the scenarios are related to configuration of azurekeyvault KMP, users specify a wrong value for tenantID or ClientID that is required for the KMP resource. Then you follow the description of this issue to check the error, you will find a lengthy call stack is shown.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants