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)
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.
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.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.