-
Notifications
You must be signed in to change notification settings - Fork 367
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
🐛 add support for standalone virtualworkspace server #2407
🐛 add support for standalone virtualworkspace server #2407
Conversation
Some of the e2e tests are failing hence marking this as WIP until resolved, any help with that or initial review feedback is welcome :) |
2347ae9
to
3cf20ac
Compare
2f0a93a
to
c60b0e6
Compare
Thanks for the review feedback @ncdc - I pushed an update which fixes most (but not yet all) of the e2e failures, will leave this as WIP until all tests are green and the review feedback is addressed 👍 |
c60b0e6
to
7303446
Compare
90e3c6b
to
13fd4fd
Compare
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.
Seems mostly reasonable, but boy is that an enormous test setup
e2c1812
to
c4fa992
Compare
c4fa992
to
27a1c3e
Compare
@ncdc quick update on this as I'm still struggling somewhat to get the e2e tests all working in standalone-vw mode AFAICS some tests (for example Locally testing (with sharded-test-server configured with
We see that the test sometimes passes, and if I increase the test timeout it can pass reliably - in some test runs locally I'm seeing a delay of around 50 seconds waiting for the In the shard logs we can see the proxied requests, and there are some bootstrapping authz errors which I'm thinking may be related?
If you have any suggestions where to look next that would be welcome, currently I'm not very sure why there is such a long delay in the workspace creation. |
@hardys this particular test will go away as part of the workspace refactoring. Do you have a list of all the tests you're having problems with, and we can see if any of them still need addressing? |
@ncdc I've mostly been testing e2e-sharded-minimal locally so I don't yet have an exhaustive list, but I'm seeing I'm interested to understand why the long delay though, with the in-process VW the workspace list succeeds pretty much immediately, any idea why is it taking nearly a minute in standalone VW mode? |
Not offhand. Maybe something to do with the workspace authz cache (which will be going away as part of the workspace refactor) |
Ack thanks, sounds like I should probably pause work on this and rebase after the workspace refactor lands :) |
27a1c3e
to
0d97d5c
Compare
@hardys let me know if you need help after the rebase, from the logs it looks like the requesting user for the SAR passes all authorizers but the local and bootstrap policy one for the |
0d97d5c
to
4d8d130
Compare
cb13f1c
to
57b01aa
Compare
57b01aa
to
a99f0a9
Compare
/test e2e-shared Looks like #1878 |
Co-authored-by: Andy Goldstein <andy.goldstein@redhat.com>
Co-authored-by: Andy Goldstein <andy.goldstein@redhat.com>
Co-authored-by: Andy Goldstein <andy.goldstein@redhat.com>
Co-authored-by: Andy Goldstein <andy.goldstein@redhat.com>
Align with the shard WaitForReady pattern ref kcp-dev#2303 as a step towards enabling multiple VW servers when there are multiple shards
Avoid calculating the port in multiple places, and also use JoinHostByPort instead of Sprintf
a99f0a9
to
b32ddf0
Compare
/hold cancel @ncdc @stevekuznetsov this is ready for another review when you get some time, thanks! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ncdc 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 |
In kcp-dev#2407 we introduced this validation, but it doesn't handle the case where the VW server is not standalone, but you still want to specify --shard-virtual-workspace-url This scenario is likely when deploying a sharded environment, since you'll want the VW traffic to go via the front-proxy regardless of whether the VW server is standalone or not.
Partially reverts logic introduced in kcp-dev#2407 so we don't unconditionally use the external URL - when non-standalone VW mode is used we still need the old behavior, or the loopback client can't access the VW server. This breaks shard bootstrapping (evidently not in our e2e scenarios, but in a real deployment where probes mean the proxy isn't ready until the shard bootstrap is complete)
Partially reverts logic introduced in kcp-dev#2407 so we don't unconditionally use the external URL - when non-standalone VW mode is used we still need the old behavior, or the loopback client can't access the VW server. This breaks shard bootstrapping (evidently not in our e2e scenarios, but in a real deployment where probes mean the proxy isn't ready until the shard bootstrap is complete)
Partially reverts logic introduced in kcp-dev#2407 so we don't unconditionally use the external URL - when non-standalone VW mode is used we still need the old behavior, or the loopback client can't access the VW server. This breaks shard bootstrapping (evidently not in our e2e scenarios, but in a real deployment where probes mean the proxy isn't ready until the shard bootstrap is complete)
Summary
This is another change decoupled from the shard-standalone-vw branch from @ncdc
Related issue(s)
Follow up to ##2297 and #2303 which also merged changes from the WIP branch
Fixes #2254
Fixes #2056