Discuss tweaking version compatibility with elasticsearch

[ppf2]

Continuing the discussion from here. Re-posting with @spalger feedback below:

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]

One more comment:

If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run (🚫). "

Does this mean that we do not expect to have the same situation (like today) moving forward - i.e. ES 2.4.0 is the latest version released for Elasticsearch and Kibana 4.6.1 is the latest Kibana version released (so ES 2.4.0 is 1 older version than Kibana's 4.6.1)? This is something to consider esp. for Cloud (like how Cloud has upgraded to Kibana 4.6.1 now with ES still staying on 2.4.0).

[epixa]

That situation will not happen in 5.0 onward. Any bump to any part of our stack will bump the whole stack.

On Sep 14, 2016, at 1:49 AM, Pius notifications@github.com wrote:

One more comment:

If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run (🚫). "

Does this mean that we do not expect to have the same situation (like today) moving forward - i.e. ES 2.4.0 is the latest version released for Elasticsearch and Kibana 4.6.1 is the latest Kibana version released (so ES 2.4.0 is 1 older version than Kibana's 4.6.1)? This is something to consider esp. for Cloud (like how Cloud has upgraded to Kibana 4.6.1 now with ES still staying on 2.4.0).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[LeeDr]

Let's go through a scenario or two of a patch release and see if we agree how it plays out.

We have to patch Kibana because of a security issue. So let's say we build the whole stack at 5.0.1.
I think this means each product has to branch and update versions?
We test the whole stack at 5.0.1 (as much as this one fix needs testing).
We release the whole stack.
Maybe the Kibana release notes describe the fix?
The other products don't update release notes? Or do they say nothing changed?
A customer knows only Kibana changed and wants to upgrade only that product but can't because we don't allow Kibana to be 1 patch version ahead of Elasticsearch? :-(
I think this would be totally unacceptable. I'm sure the effort to upgrade large Elasticsearch clusters is not trivial in production.
Patch releases should NOT break compatibility with the same major.minor of the other products. If the change does break compatibility it must bump at least the minor version (so 5.1.0 in this case). Then it's clear that everything needs to be updated.

Same scenario but with an Elasticsearch patch. Do we force the customer to upgrade Kibana? And all the plugins? That also means we force ourselves to do a (minimal) round of testing when we haven't changed anything.

[epixa]

The upgrade policy in 5.0 onward is that you should upgrade the whole stack together even for patch versions.

That said, we could probably add a case to be a little less strict at the patch level. So even though technically our upgrade policy doesn't support this, Kibana wouldn't fail to run if ES was at a low patch level and it would instead render out a warning message to console that says that this setup is unsupported and that we encourage them to upgrade their ES nodes as soon as possible.

Edit: That would at least technically allow a user apply an urgent security fix or something to Kibana and then upgrade the rest of their stack next, though that wouldn't be a supported workflow.

[epixa]

I'm closing this discuss ticket in favor of the consensus change: #8515