Update elasticsearch plugin to require ES to have the same version as Kibana.

[cjcenizal]

Problem

We were previously configuring the elasticsearch plugin with a hard-coded engineVersion value, and then using the semver package to ensure ES versions matched it.

Now that we're locking Kibana and ES versions, we have new rules that determine whether an ES version is compatible, incompatible, or merits a warning with a version of Kibana (This chart is outdated, scroll down for a newer one):

🚫 Incompatible

⚠️ Warning

💚 Compatible

Kibana version	ES -1.0.0	ES 1.-1.0	ES 1.1.-1	ES 1.1.1
-1.0.0	💚	🚫	🚫	🚫
1.-1.0	🚫	💚	⚠️	⚠️
1.1.-1	🚫	🚫	💚	⚠️
1.1.1	🚫	🚫	🚫	💚

Changes

• Remove engineVersion from elasticsearch plugin config.
• Use Kibana package.json version instead.
• Use new rules, documented in README.
• Log warning if ES is newer than Kibana.
• Add isEsCompatibleWithKibana, isEsNewerThanKibana, parseVersionNumbers, and kibanaVersion.
• Remove versionSatisfies.

[spalger]

esvm is updated and master snapshots should now match kibana version

[cjcenizal]

jenkins, test this

[spalger]

How about **Server warnings** are logged by the Kibana Server if Elasticsearch.... Many people won't be running Kibana via the command line, and will only see the logging output if they look at the log files.

[cjcenizal]

Great point

[spalger]

I realize that the previous implementation did much of this, but I would prefer that we didn't reimplement the methods provided by the semver module for parsing and comparing versions.

I think we could delete 100+ lines of code+tests by switching to semver.gt(esVersion, kibanaVersion) and semver.major/minor/patch(version)

[spalger]

Should probably delete this comment

[cjcenizal]

Clearly I didn't review this PR myself before asking for a review!

[cjcenizal]

New comparison chart:

[spalger]

We should probably return here, right?

[epixa]

Rather than imperatively building these arrays in the same loop, how about just filtering?

const incompatibleNodes  = info.nodes.filter(esNode => {
  return !isEsCompatibleWithKibana(esNode.version, kibanaVersion);
})

const warningNodes = info.nodes.filter(esNode => {
  return semver.gt(esNode.version, kibanaVersion);
});

[cjcenizal]

This would collect warningNodes for versions of ES that have a newer major number, but those should only go into the incompatibleNodes. So it's better to do them in one loop and exit early as @spalger suggested above.

[pickypg]

New comparison chart:

Should we actively block Kibana from working with a patch-release of ES that's older than it? If I happen to upgrade Kibana before completing a rolling upgrade of ES, then I think that I would be quite annoyed to find that it was broken until I finished the rolling upgrade. More importantly, the unified release of the full stack will mean that inevitably some ES patch releases (and Kibana patch releases) will be unchanged.

If there's something broken in ES 6.1.1 (the example above), then we can manually add the exception to Kibana 6.1.2 to prevent it from working with it.

I think the comms between Kibana and ES are stable enough at this point that we should be able to largely handle version discrepancies (5.0+), with features that draw the line in the sand causing hard breaks.

[spalger]

LGTM, I think that this PR is a great step in the right direction for es/kibana compatibility.

@pickypg While I think that your suggestion makes logical sense in terms of what versions should mean, I worry it might add undue complexity to this new compatibility/upgrade story.

While this discussion has certainly been had elsewhere, and I'm sure this suggestion was explicitly decided against for good reasons, my feelings about it totally revolve around keeping the compatibility story as memorable and predictable as possible.

Saying "you must always upgrade Elasticsearch before Kibana" seems easier to remember than "you must always upgrade Elasticsearch before Kibana, unless it's simply a patch upgrade, in which case you can upgrade Kibana first or even outright ignore Elasticseach, unless there is an exception in table X."

[pickypg]

Saying "you must always upgrade Elasticsearch before Kibana" seems easier to remember than "you must always upgrade Elasticsearch before Kibana, unless it's simply a patch upgrade, in which case you can upgrade Kibana first or even outright ignore Elasticseach, unless there is an exception in table X."

I agree that the former is definitely simpler and this PR is a simplification on the current story. But it's also a lot more common for users to go from x.y to x.[y + n] where n > 1 and I don't see that in the chart above (only where n = 1).

[spalger]

Good point, as long as Elasticsearch upgrades first that is supported, but we should add an example of that to the chart.

[spalger]

@pickypg pointed out that we don't illustrate running from 6.1 against something like 6.5, which would be supported right?

[spalger]

See #8229 (comment)

[epixa]

We can always relax version checks, but it's hard to make them more restrictive. The change being done here is the implementation of a larger "how to upgrade the entire elastic stack" discussion that happened some months back.

Let's not get too carried away with this chart, by the way. There's an effort going on to build "upgrade" docs for the whole stack and such, which is where detailed descriptions about the upgrade process should be. People don't and shouldn't have to read our readme for this kind of stuff. The original reason why CJ wanted to add the chart and such to the readme was to better document to developers how our version checking works.

[ppf2]

I like that we are working towards syncing up the version across the stack :)

• Should we actively block Kibana from working with a patch-release of ES that's older than it?

+1. As much as we hope that users will read the docs before the upgrade, the reality is that some users will not (or miss the important points) :( so it will be nice to do a block with a descriptive message when Kibana detects that the ES version it is connecting to is running an incompatible version.

• The chart is showing that if the ES minor version is higher, it will throw a warning. Do we intend to support higher ES minor version (may have breaking changes in ES), or just higher ES patch version (typically no breaking changes in ES for patch versions)?
• All the version combinations with "Compatible" and "Warning" are the ones we will be formally testing correct?
• Also, what does warning mean here (well I know that it means ES patch/minor version number is higher)? But what does it mean from an operational/supportability point of view, eg. do we mean that the ES version is supported only during the time of a full cross stack upgrade (i.e before Kibana upgrades to the same ES version)? Or does the warning here means that the version combination is not tested?, etc..

[tsullivan]

LGTM

[spalger]

@ppf2

The chart is showing that if the ES minor version is higher, it will throw a warning. Do we intend to support higher ES minor version (may have breaking changes in ES), or just higher ES patch version (typically no breaking changes in ES for patch versions)?

Yes, we will support but warn about users running a version of elasticsearch that has a higher minor or patch version than Kibana. This way, users can upgrade elasticsearch first and then Kibana once that is complete.

All the version combinations with "Compatible" and "Warning" are the ones we will be formally testing correct?

Good question :) @LeeDr?

But what does it mean from an operational/supportability point of view

I think the idea is that Elasticsearch will be stable enough through a major version to support Kibana, as long as a minimum minor version is met, but @epixa can probably add some color here.

[ppf2]

@cjcenizal suggested earlier today to open a separate ticket for the ongoing discussion since the PR has been merged so I will move the outstanding discussion paragraphs to the new issue.

Btw, looking at the merged readme file again, I think we mean to say "ES minor number is newer." here ?

[cjcenizal]

Great catch @ppf2 ! Thanks!