-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[http] Do not do client version check on serverless as we do for onprem #159101
[http] Do not do client version check on serverless as we do for onprem #159101
Conversation
…gured, we do not do client version checks
it('accepts requests with any version passed in the version header', async () => { | ||
await supertest(innerServer.listener) | ||
.get(testRoute) | ||
.set(versionHeader, 'what-have-you') | ||
.expect(200, 'ok'); | ||
}); |
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.
This is the most important change/difference. We do not block for version headers.
handlerResolution: schema.oneOf([schema.literal('newest'), schema.literal('oldest')], { | ||
defaultValue: 'oldest', | ||
}), |
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.
Bring this more in line with other ways of configuring Kibana for serverless
@@ -31,97 +27,29 @@ const setupDeps = { | |||
executionContext: executionContextServiceMock.createInternalSetupContract(), | |||
}; | |||
|
|||
interface HttpConfigTestOptions { |
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.
Removed and handled by the updated createConfigService
utility.
if (config.versioned.strictClientVersionCheck !== false) { | ||
// add check on version | ||
registrar.registerOnPostAuth(createVersionCheckPostAuthHandler(env.packageInfo.version)); | ||
} |
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.
nit: I wonder if we still want to warn via some custom header in the response.
This would help when troubleshooting HARs, or even, potentially using that on the browser to warn the user that they should refresh the page.
WDYT?
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.
I like that idea! As you suggest, this is one way to drive the "update available" UX we've spoken about... Currently it will only detect a new version when we ship a new stack version --- this will not be sufficient for more continuous updates. I think updating the Kibana version to contain a git hash or build nr or something would be needed...
I'd like to spend a bit more time thinking about how we want to approach that specifically. Do you think it is still worth adding a header like this now? If so, do you think we should just reuse the existing kbn-version
header and set it to update-available
or out-of-sync
?
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.
Opened #159127
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.
IMO, we should just include the version in the header all the time, and add metadata to our logging-- not just error logging-- with the client version and server version. That metadata will be invaluable to not only knowing if a mismatch is contributing to an error, but also if an error has spiked on a particular version of client + server, and how many clients are "lagging" the upgrade curve.
The version mismatch will drive the UX, for certain, but I would love to have requests and errors tagged all the time. The mismatch will be one data point in an investigation... an important one, but not the only one.
Pinging @elastic/kibana-core (Team:Core) |
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.
Looking good to me as a first stage
private readonly options: RouterOptions = { | ||
isDev: false, | ||
versionedRouteResolution: 'oldest', | ||
} |
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.
NIT: I know it was done to avoid having to change all the constructor calls, but I wonder how safe having this options
be an optional parameter is. I don't think we're using the Router
in that many places, so maybe making options
mandatory now could make sense, WDYT?
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.
Sounds good to me!
versioned: schema.object({ | ||
// Which handler resolution algo to use: "newest" or "oldest" | ||
handlerResolution: schema.oneOf([schema.literal('newest'), schema.literal('oldest')], { | ||
defaultValue: 'oldest', | ||
}), |
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.
NIT: Handler resolution or version resolution? Is the "oldest handler" really a valid term?
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.
Will change to versionResolution
packages/core/http/core-http-server-internal/src/lifecycle_handlers.test.ts
Outdated
Show resolved
Hide resolved
export const createConfigService = ({ | ||
server, | ||
externalUrl, | ||
csp, | ||
}: Partial<{ | ||
server: Partial<HttpConfigType>; | ||
externalUrl: Partial<ExternalUrlConfigType>; | ||
csp: Partial<CspConfigType>; | ||
}> = {}) => { |
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.
👍 the stub config definition is way better that way
* main: (199 commits) [Lens] Add custom formatter within the Lens editor (elastic#158468) [Uptime] Hide app if no data is available (elastic#159118) [CodeEditor] Add grok highlighting (elastic#159334) Expose decoded cloudId components from the cloud plugin's contract (elastic#159442) [Profiling] Use collector and symbolizer integrations in the add data page (elastic#159481) [Infrastructure UI] Hosts View: Unified Search bar with auto-refresh enabled (elastic#157011) [APM] Add feature flag for not available apm schema (elastic#158911) [Lens] Remove deprecated componentWillReceiveProps usage (elastic#159502) [api-docs] 2023-06-13 Daily api_docs build (elastic#159536) [data views] Use versioned router for REST routes (elastic#158608) [maps] fix geo line source not loaded unless maps application is opened (elastic#159432) [Enterprise Search][Search application]Fix Create Api key url (elastic#159519) [Security Solution] Increase timeout for indexing hosts (elastic#159518) dashboard Reset button disable (elastic#159430) [Security Solution] Unskip Endpoint API tests after package fix (elastic#159484) [Synthetics] adjust alert timing (elastic#159511) [ResponseOps][rule registry] Remove usages of `refresh: true` (elastic#159252) Revert "Remove unused package (elastic#158597)" [Serverless] Adding config to disable authentication on task manager background worker utilization API (elastic#159505) Remove unused package (elastic#158597) ...
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @jloleysens |
Summary
This PR introduces two changes:
(1) Refactors the handler resolution logic to not depend on the
--serverless
cli arg by adding a new piece of configserver.versioned.routeResolution
that acceptsnewest | oldest
. This piece of config is passed down instead of theserverless
cli arg as well as updating test cases(2) Adds a new piece of config to turn off the client version checking. This will be needed for rolling upgrades to allow old browser traffic to reach new Kibana servers when there is stack version change.
Close #158723
Open questions