X-pack plugin version hell [feature request?]


(Guy Wicks) #1

Something that STOPS me from using the otherwise very useful x-pack on my cluster is that I have to exactly match the ES and x-pack version numbers. I've been in situations where my ES server has patched, upgraded and then failed to restart - due the the ES x-pack plug in now being out of date.

Would it be possible to have the x-pack plug in ALSO available in the RPM repository so that it can be kept in step with ES and Kibana?

Or - can the x-pack plug in have a more relaxed tolerance for matching version numbers - something that ES and Kibana has thankfully put in place.

Or - can the ES rpm have a 'disable any old plug-ins' feature (and associated warning) as it upgrades

Or - can the ES rpm FAIL TO INSTALL if there are plug-ins that will be incompatible

One of these options has to be better than the current situation (or I just don't use otherwise useful plug-ins)

Thanks in advance.


(Ryan Ernst) #2

You need to make removing and re-installing plugins part of your upgrade process. This is not specific to x-pack: it is relevant for all plugins, regardless of whether they are developed by elastic or otherwise.


(Guy Wicks) #3

That didn't really answer the question(s), it rather just dimissess it ! I'm trying to reduce the admin overhead time on my installation, and suggest ways that you could support this for your users.

The x-beats plugin is totally under your control, and it is something that you encourage implementers to use.

It was of some interest that you DO package up x-beats with your Docker deployment.


(system) #4

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.