enable the system callback url #924
Conversation
| // Enable the system callback URL for worker targets. | ||
| // NOTE that the URL scheme is fixed to HTTP since the dev server doesn't support TLS at the time of writing. | ||
| // The callback URL template is used as a fallback for external targets. | ||
| dynConf[nexusoperations.UseSystemCallbackURL.Key()] = true |
There was a problem hiding this comment.
I am curious about these Nexus dyn configs in general. Why can't a user be asked to configure these dynamic configs the same way they would if configuring any other self-hosted server? Why does other self-hosted environment not have these defaults and why must this self-hosted environment uniquely have these defaults here?
The caching and RPC limit updates make sense for local dev server, but feature defaults to not IMO. Our self-hosted dyn config requirements should be the same regardless of whether it's dev server self-hosted, docker self-hosted, binary self-hosted, etc.
There was a problem hiding this comment.
OSS server v1.31 will have this toggle enabled by default and we can remove the URL templates here.
After v1.31 no dc overrides are required for nexus.
There was a problem hiding this comment.
I just removed 2 other DCs.
There was a problem hiding this comment.
We didn't want users to have to struggle to enable Nexus. That's why these configs were here in the first place. Starting server 1.31, Nexus will work OOTB with no dynamic config overrides.
There was a problem hiding this comment.
Also note that since the HTTP port is randomly allocated by default (still considered experimental), it was deemed to difficult to configure this for a user.
There was a problem hiding this comment.
FWIW, the behavior of nexus callbacks is the same before and after this PR. Before, callbacks could only point to the dev server and after they could only point to the dev server.
After 1.31 this config will be inline with the default config of the normal server release. There's a TODO to remove these configs entirely.
There was a problem hiding this comment.
After 1.31 this config will be inline with the default config of the normal server release
We should wait then IMO. This CLI is for 1.30 not 1.31, and I would expect the same dyn configs to be required for users of a feeature across all releases of 1.30 (CLI, temporal release binary, docker image, helm chart, etc)
There was a problem hiding this comment.
Just want to clarify that this isn't for enabling Nexus, it's enabled by default. This is for making Nexus easier to use in the dev server. There is no need to walk back the decision we made a while ago to make Nexus work without extra user configuration.
This config is more for QOL, similar to HistoryCacheHostLevelMaxSize or FrontendMaxNamespaceVisibilityRPSPerInstance.
There was a problem hiding this comment.
This is for making Nexus easier to use in the dev server. There is no need to walk back the decision we made a while ago to make Nexus work without extra user configuration.
Nexus should be made easier to use in all 1.30 servers. If we decided not to do that for 1.30 servers, makes sense to do it for 1.31 servers. Not sure how that is related to CLI, I assume your decision to make Nexus work without user configuration is not CLI specific.
This config is more for QOL, similar to HistoryCacheHostLevelMaxSize or FrontendMaxNamespaceVisibilityRPSPerInstance.
Would users need to set this dyn config for all the other non-CLI 1.30 servers they set up to have teh same user/operator experience? Or is it an internal-only/non-user-facing optimization?
There was a problem hiding this comment.
Would users need to set this dyn config for all the other non-CLI 1.30 servers they set up to have teh same user/operator experience?
Yes, they would have to set the templating for pre-1.30 versions
Co-authored-by: Roey Berman <roey.berman@gmail.com>
3 participants
What was changed
Why?
temporalio/temporal#8308
Checklist
Closes
How was this tested: