-
Notifications
You must be signed in to change notification settings - Fork 277
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
Boundary Desktop Issues with 0.15.0 #4370
Comments
Currently seeing the same issues in my customer base. I believe this issue from the controller logs is related (largely based on timing of log event, I haven't dug into the Controller code to verify) {
"id": "8fZb3SIAQW",
"source": "https://hashicorp.com/boundary/ip-10-11-67-159.ec2.internal/controller",
"specversion": "1.0",
"type": "error",
"data": {
"error": "pagination.List: pagination.list: unknown, unknown: error #0: Status: 500, Kind: \"Internal\", Error: \"output fields not found when building scope proto\"",
"error_fields": {
"Code": 0,
"Msg": "",
"Op": "pagination.List",
"Wrapped": {
"Code": 0,
"Msg": "",
"Op": "pagination.list",
"Wrapped": {}
}
},
"id": "e_j3SAdXQcIm",
"version": "v0.1",
"op": "handlers.ErrorHandler",
"request_info": {
"id": "gtraceid_m74aXX1xkERqrZdmXOv1",
"method": "GET",
"path": "/v1/scopes?filter=(%22%2Fitem%2Ftype%22%20%3D%3D%20%22project%22)&recursive=true&scope_id=global",
"public_id": "at_mQrSM3rcTg",
"client_ip": "10.11.57.158"
},
"info": {
"msg": "internal error returned"
}
},
"datacontentype": "application/cloudevents",
"time": "2024-02-07T16:03:37.400150659Z"
} |
Successfully reproduced this issue via the CLI by having the client issue $ boundary scopes list -recursive
Error from controller when performing list on scopes
Error information:
Kind: Internal
Message: output fields not found when building scope proto
Status: 500
context: Error from controller when performing list on scopes The issue seems to be tired to permissions in some way. Administrators with |
Hey folks @zellio & @BoswellB35 -- thanks for using boundary & thanks for the updates here. We're investigating this internally and will provide an update once we have one |
An interim solution we have found is to grant broad no-op access to all users on all scopes in the global scope We use ldap groups for all of our users but roughly we have ended up with three roles
|
I'm also seeing this issue with Boundary 0.15.0 with Boundary desktop 2.0.0. I'm seeing the same 500 error as @zellio has shown above but I'm not able to resolve the issue by giving the suggested permissions. I'm unable to get beyond the unsupported controller version so tried to give the @zellio do you have any more information about how you overcame the docker desktop issue? |
@william00179 I haven't tested this issue in Docker. My testing and resolution is from a production deploy on AWS ECS. For reference though I had to make sure that all users had no-op on all scopes in the global scope |
We're having similar issues with Boundary (OSS) controller version 0.15.2 and Boundary Desktop version 2.0.0-2.0.1. See attached error message. The Would be great to have some steps to debug this @AdamBouhmad EDIT: After updating my grant strings to use |
We tried everything we could think of to fix this, only thing that worked was dropping the database and recreating everything (we manage everything via Terraform), after that it is working fine I suggest starting a local boundary in dev mode and try to replicate your environment: same auth method, same roles, similar number of scopes/projects… we did that and everything worked as expected, that’s where we decided to drop the database I know it’s not a good solution but that’s what we did |
So I think this is related to the When |
Following up on this I tore down my test environment, database and all, and started fresh on 0.15.2. Can confirm that after I was then able to connect to that deployment via Desktop version 2.0.1. Obviously this would be a less-than-ideal solution for my production environment, even with things under Terraform control. Hoping we can see a fix that doesn't require dropping the database. |
Should be fixed by hashicorp/boundary-ui#2199 |
This issue is still occurring in 0.15.4 $ boundary scopes list -recursive Error information: $ boundary version Version information: $Permissions for u_anon: @AdamBouhmad Do you have any feedback on this issue? |
@wichitalineman what version is your Boundary Controller running on? 0.15.4? If so I can check & see if we can reproduce, as this should have been fixed with hashicorp/boundary-ui#2199 |
@AdamBouhmad I can confirm I'm still seeing this issue on 0.15.4 controller and workers with the latest Boundary Desktop app also. Let me know what I can provide so you can reproduce the issue. |
@AdamBouhmad From the controller we see these logs after anyone logs on the Boundary desktop. The same error occurs with user/pass auth or oidc:
We tested Boundary Desktop 1.7.1 and 2.0.2 and both had the same issue. Please let me know what further info I can provide. |
The fix hasn't been released yet, only merged to |
This is no longer happening with 0.16.0. Thanks for the fix. |
Describe the bug
I've been testing the 0.15.0 release of Boundary, and have had trouble connecting to it via multiple versions of Boundary Desktop.
I initially tried connecting to my 0.15.0 controller using Version 1.7.1 of Boundary Desktop (which uses CLI Version 0.14.2). This produced the following error after entering my Cluster URL:
I then updated to Boundary Desktop Version 2.0.0 (which uses CLI Version 0.15.0). This produced the following error after entering the Cluster URL:
While the first error is not too surprising given a major version change, the second is perplexing as there is no newer version of the controller for me to use.
To Reproduce
Expected behavior
Either version of Boundary Desktop should connect to the controller running Boundary version 0.15.0 and display the usual login prompt.
Additional context
I am running a Boundary deployment with a single controller and worker in docker containers on Ubuntu instances, both on version 0.15.0. I've not made any configuration changes to my previous controller or worker deployment outside of updating the version, though I did not see anything in the release notes that suggested I would need to. I am running Boundary Desktop on macOS Sonoma Version 14.3, installed via direct download. My current production deployment of Boundary uses version 0.14.2; Desktop 1.7.1 works fine with that, while Desktop 2.0.0 produces the error in the second screenshot, which I would expect in that case.
The text was updated successfully, but these errors were encountered: