Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display plugins versions #18683

Merged
merged 1 commit into from Sep 12, 2016

Conversation

Projects
None yet
6 participants
@Mogztter
Copy link
Contributor

commented Jun 1, 2016

This is useful to determine if a plugin needs to be updated when using deployment automation solution (like Ansible).

A similar feature is now available in Kibana: elastic/kibana#7221

Display plugins versions
This is useful to determine if a plugin needs to be updated when using deployment automation solution (like Ansible).
@rjernst

This comment has been minimized.

Copy link
Member

commented Jun 1, 2016

The verbose option was extended to display all plugin properties in #18051.

@Mogztter

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2016

Yes I saw but the output is on multiples lines (ie. harder to parse with an automation tool).
The format name@version is quite common and the behavior will be the same across Kibana and Elasticsearch (and soon Logstash ?)

The verbose output is still useful for human.

@rjernst

This comment has been minimized.

Copy link
Member

commented Jun 1, 2016

Human consumption is all you can really do. Knowing the plugin version doesn't tell you if it needs updating. Any time you update elasticsearch, plugins need to be updated, because they currently must be built against each specific version of elasticsearch.

I think the non verbose output should stay as simply listing the plugin names installed, eg like ls just lists file names. But I have marked this for discussion.

@jasontedor

This comment has been minimized.

Copy link
Member

commented Jun 1, 2016

I think the non verbose output should stay as simply listing the plugin names installed, eg like ls just lists file names.

+1

@Mogztter

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2016

Human consumption is all you can really do. Knowing the plugin version doesn't tell you if it needs updating. Any time you update elasticsearch, plugins need to be updated, because they currently must be built against each specific version of elasticsearch.

But you can still have a new version of a plugin without a new version of Elasticsearch ?

I think the non verbose output should stay as simply listing the plugin names installed, eg like ls just lists file names. But I have marked this for discussion.

"Make everything as simple as possible, but not simpler".
If I want to know the content of a directory, I will use ls not a Java program 😉

I think the plugin version is an important information and ListPluginsCommand already knows this information, why not make it available and easy to read by an automation tool ? What are the drawbacks of adding this piece of information ?

Here's some benefits:

  • Check that a plugin need to be updated
  • Check that the plugin version is compatible with Elasticsearch version
  • Do not remove/install a plugin if the version did not change

Right now, in Ansible the basic idea is remove everything, install everything: https://github.com/elastic/ansible-elasticsearch/blob/master/tasks/elasticsearch-plugins.yml#L20 😒

@rjernst

This comment has been minimized.

Copy link
Member

commented Jun 1, 2016

Right now, in Ansible the basic idea is remove everything, install everything

That is what must happen for all official elasticsearch plugins. You are correct that community plugins may release multiple versions per elasticsearch version. But knowing what version is currently installed of a community plugin does not tell you anything about whether there is another version, and upgrading elasticsearch means another version of that community plugin must be installed.

@Mogztter

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2016

But knowing what version is currently installed of a community plugin does not tell you anything about whether there is another version

Ansible will know because I will tell him to install a (newer) version for this plugin. Being able to determine if I need to remove a community plugin in order to install a newer version will be really useful.
IMHO this is just tiny addition that can be useful to users and will certainly make my life easier 😄

@dadoonet

This comment has been minimized.

Copy link
Member

commented Jun 24, 2016

We discussed it on fix it friday and found that it could be a nice feature to have. We don't see any drawback by adding this.
It's also consistent with the rest of the stack (kibana as explained in the PR) and if it makes our users life easier, let's do it.

I'm changing the label to "review".

@rjernst As you were not available for this Fix It friday session, feel free to comment and raise any objection if any and change back the label to "discuss".

@Mogztter

This comment has been minimized.

Copy link
Contributor Author

commented Jun 24, 2016

Thanks @dadoonet !

@Mogztter

This comment has been minimized.

Copy link
Contributor Author

commented Aug 19, 2016

@dadoonet Any news ?

@dakrone

This comment has been minimized.

Copy link
Member

commented Sep 12, 2016

This LGTM, I will merge this

@dakrone dakrone merged commit 9411f18 into elastic:master Sep 12, 2016

1 check passed

CLA Commit author has signed the CLA
Details
@dakrone

This comment has been minimized.

Copy link
Member

commented Sep 12, 2016

@Mogztter merged this, thanks!

@dakrone

This comment has been minimized.

Copy link
Member

commented Sep 12, 2016

Backported to 5.x and 5.0

@dadoonet

This comment has been minimized.

Copy link
Member

commented Sep 13, 2016

Thanks @dakrone! I was planning to merge it today! \o/

@Mogztter

This comment has been minimized.

Copy link
Contributor Author

commented Sep 13, 2016

Thanks \o/
Looking forward to the next 5.0 release ;)

@jasontedor

This comment has been minimized.

Copy link
Member

commented Oct 11, 2016

This has been reverted in #20807.

@Mogztter

This comment has been minimized.

Copy link
Contributor Author

commented Oct 11, 2016

Wait what... but why ? 😭

@jasontedor

This comment has been minimized.

Copy link
Member

commented Oct 11, 2016

For the initial reasons given against this PR and additionally as elaborated in #20668.

@Mogztter

This comment has been minimized.

Copy link
Contributor Author

commented Oct 11, 2016

Just read #20668

I was against that change because it's conflating a human-readable API with a machine-readable API.

Fair enough but where can I find a machine-readable API ?
As a workaround, you can use localhost:9200/_cat/plugins API but the server must be running.
I think I will just create a tiny script to read the properties file.

@jasontedor

This comment has been minimized.

Copy link
Member

commented Oct 13, 2016

Fair enough but where can I find a machine-readable API ?

There isn't one, but that does not mean we should mix the two.

I think I will just create a tiny script to read the properties file.

I'm wondering why you don't unconditionally uninstall and then install the right version?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.