Kibana Client Will Detect Version Changes of Kibana Server

[petrklapka]

!!Working Draft Requirements:

In Serverless deployments, the Kibana client will:

• Detect when the Kibana server has been upgraded.
• Make a log entry when a mismatch between Client & Server versions begins
• Generate a telemetry event when a mismatch between Client & Server versions begins
• Make a log entry when a mismatch between Client & Server versions ends (client is refreshed)
• Generate a telemetry event when a mismatch between Client & Server versions ends (client is refreshed)
• Allow for identifying errors that occur during the time the Client & Server versions are mismatched.

Implementation of version change detection is discussed here.

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[jloleysens]

Thanks for creating this issue!

identifying errors that occur during the time the Client & Server versions are mismatched

We don't have a way do this for serverless today (I guess that is what this issue is about :) ).

More specifically: on serverless we will be deploying versions "between" stack versions but we only communicate the stack version today (i.e. 8.9.0) via the kbn-version header.

We'd need to modify the version being sent via kbn-version to something that can represent a new Kibana build (as opposed to a new stack version). Top of my head I can imagine two approaches:

1. We update the kbn-version value with a build number: something like 8.9.0+123abcdefg and keep it SemVer compliant.
2. Change kbn-version to something entirely new like a build hash 123abcdefg, non SemVer compliant

I prefer (1), I also think it will be easier to implement as it remains largely compatible with how this value is used today, but I can also see a case for (2) in that "stack version" is not really a thing on serverless anymore.

Note: we have a way to get a unique build number for Kibana, this will be a number like 64910 not an actual commit SHA. In development we just set this to Node.js' max int. See:

https://github.com/elastic/kibana/blob/a39531edce1c59e18c1f5b77e62cf77ac5e43ef2/src/dev/build/lib/get_build_number.ts

(CC @mistic @jbudz to keep me honest)

Probably good enough for our purposes but personally I think a commit SHA or git tag would be more useful.

---

mismatch between Client & Server versions begins
mismatch between Client & Server versions ends (client is refreshed)

I'm not sure that we have a way of reliably knowing that a specific mismatch has started or ended bc we'd need a way to uniquely ID that browser and I don't think we have that today.

Identifying errors that result from a given request in a generic way might be tricky. Perhaps a starting point could be to check for any response >399, check the version and create a log.

[jbudz]

Note: we have a way to get a unique build number for Kibana, this will be a number like 64910 not an actual commit SHA. In development we just set this to Node.js' max int. See:

https://github.com/elastic/kibana/blob/a39531edce1c59e18c1f5b77e62cf77ac5e43ef2/src/dev/build/lib/get_build_number.ts|

(CC @mistic @jbudz to keep me honest)

Yep looks good. Build number tracks the total number of commits. Build 64910 could point to two different branches. I don't think it's likely to occur but if there is a uniqueness constraint it would be safer to check both version and build number.

Change kbn-version to something entirely new like a build hash 123abcdefg, non SemVer compliant

I'm out of date here. Are there possible situations where endpoints will need to know a more granular version than API version? Would knowledge of how old a build is be useful vs version mismatch?

[petrklapka]

Thanks for the info @jloleysens and @jbudz . The ask is very much a draft in progress, I wanted something as a discussion starting point. Definitely expect it to change!

@clintandrewhall mentioned in a slack chat that the draft logging and telemetry points aren't necessary, and that a cleaner approach would be to add metadata to requests and logged errors.

@sixstringcode and @osmanis - since we moved away from a UX notification of the version mismatch state, what is it that PM wants out of the detection? Identifying errors that happen while the versions are mismatched was mentioned, which is what inspired the initial draft ask.

[jloleysens]

Would knowledge of how old a build is be useful vs version mismatch?

@jbudz I was proposing using kbn-version header as a version value that serves a different purpose from API versions.

kbn-version could be used to track unique Kibana UI and server builds (kinda as it does today, but more granular): the idea being a Kibana server would be aware that it is talking to a UI from an older build even if it is using all the latest API endpoints. The value of this is mainly for observability and debugging.

But perhaps there is a different way to achieve this :)

[petrklapka]

After discussing with @osmanis and @sixstringcode , the product requirement has been refined to "Be able to tell when a client/server mismatch is occurring, and be able to identify errors that happen during the mismatch." This does NOT assume that errors that occur during the mismatch are caused by it.

Since this can be accomplished in a much simpler way by adding version data to request and response headers, and there is no requirement for any additional UX or user interaction for the MVP, these requirements are deprecated.

The main discussion of how Kibana will communicate the availability of an upgrade from the server to the client is here.