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

[http] Do not do client version check on serverless as we do for onprem #159101

Merged

Conversation

jloleysens
Copy link
Contributor

@jloleysens jloleysens commented Jun 6, 2023

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 config server.versioned.routeResolution that accepts newest | oldest. This piece of config is passed down instead of the serverless 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

  • Do we want to make the version check still take major version bumps into account?

@jloleysens jloleysens changed the title [http] Do not do version check on serverless [http] Do not do client version check on serverless as we do for onprem Jun 6, 2023
@jloleysens jloleysens added Feature:http Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc release_note:skip Skip the PR/issue when compiling release notes v8.9.0 labels Jun 6, 2023
@jloleysens jloleysens self-assigned this Jun 6, 2023
Comment on lines +338 to +343
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');
});
Copy link
Contributor Author

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.

Comment on lines 172 to 174
handlerResolution: schema.oneOf([schema.literal('newest'), schema.literal('oldest')], {
defaultValue: 'oldest',
}),
Copy link
Contributor Author

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 {
Copy link
Contributor Author

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.

Comment on lines +70 to +73
if (config.versioned.strictClientVersionCheck !== false) {
// add check on version
registrar.registerOnPostAuth(createVersionCheckPostAuthHandler(env.packageInfo.version));
}
Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened #159127

Copy link
Contributor

@clintandrewhall clintandrewhall Jul 10, 2023

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.

@jloleysens jloleysens marked this pull request as ready for review June 6, 2023 14:35
@jloleysens jloleysens requested a review from a team as a code owner June 6, 2023 14:35
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

Copy link
Contributor

@pgayvallet pgayvallet left a 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

config/serverless.yml Outdated Show resolved Hide resolved
Comment on lines 149 to 152
private readonly options: RouterOptions = {
isDev: false,
versionedRouteResolution: 'oldest',
}
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me!

Comment on lines 170 to 174
versioned: schema.object({
// Which handler resolution algo to use: "newest" or "oldest"
handlerResolution: schema.oneOf([schema.literal('newest'), schema.literal('oldest')], {
defaultValue: 'oldest',
}),
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will change to versionResolution

Comment on lines +29 to +37
export const createConfigService = ({
server,
externalUrl,
csp,
}: Partial<{
server: Partial<HttpConfigType>;
externalUrl: Partial<ExternalUrlConfigType>;
csp: Partial<CspConfigType>;
}> = {}) => {
Copy link
Contributor

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)
  ...
@jloleysens jloleysens enabled auto-merge (squash) June 13, 2023 11:10
@jloleysens jloleysens merged commit 7d07149 into elastic:main Jun 13, 2023
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/core-http-server-internal 51 52 +1
@kbn/core-http-server-mocks 40 42 +2
total +3
Unknown metric groups

API count

id before after diff
@kbn/core-http-server-internal 57 58 +1
@kbn/core-http-server-mocks 41 43 +2
total +3

ESLint disabled line counts

id before after diff
enterpriseSearch 16 18 +2
securitySolution 410 414 +4
total +6

Total ESLint disabled count

id before after diff
enterpriseSearch 17 19 +2
securitySolution 491 495 +4
total +6

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @jloleysens

@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Jun 13, 2023
@jloleysens jloleysens deleted the do-not-do-version-check-on-serverless branch June 13, 2023 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:http release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v8.9.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[HTTP APIs] Kibana should allow old client requests
7 participants