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

API for forcing the reload of scripts #21654

Closed
acarstoiu opened this issue Nov 18, 2016 · 6 comments
Closed

API for forcing the reload of scripts #21654

acarstoiu opened this issue Nov 18, 2016 · 6 comments
Labels
:Core/Infra/Scripting Scripting abstractions, Painless, and Mustache discuss >enhancement

Comments

@acarstoiu
Copy link

Currently (5.0) there's no way to explicitly instruct Elasticsearch to reload the disk scripts. Setting a low value for resource.reload.interval is far from optimal. What would really be useful is a way to force the reload whenever it is actually needed.

Our real-life case is when the OS package containing the scripts gets installed, we need them compiled by Elasticsearch right away (because they are used immediately after being placed in their forlder).

@clintongormley clintongormley added :Core/Infra/Scripting Scripting abstractions, Painless, and Mustache discuss >enhancement labels Nov 19, 2016
@clintongormley
Copy link
Contributor

Instead of an API for reloading scripts, we could either (1) make the reload interval dynamically updatable or (2) use resource watching so we get notified as soon as a file changes.

Bigger question though is: should we keep file based scripts or just support inline/stored scripts? (#21798)

@acarstoiu
Copy link
Author

Removal of static scripts is a security concern, which must be compensated by an access rights mechanism included in the product, not offered as an add-on.

@clintongormley
Copy link
Contributor

All you have to do to prevent users adding stored scripts is to block the PUT/POST _scripts endpoint. If you're exposing Elasticsearch to the internet without even this basic protection, then you've already lost.

@acarstoiu
Copy link
Author

How many real databases have you seen "exposed to the internet"?! The right answer is none.
Do they have access rights built in? Hell, yes.
Why? For the same reason as here, protection from inside access.

@s1monw
Copy link
Contributor

s1monw commented Dec 2, 2016

@acarstoiu thank you for your contribution. if the only purpose of your github account is to be aggressive then I think I'm good and I want to ask you to just move on. There is no room for this here and my and @clintongormley and all of the other contributors and committer time is too precious for this. You are happy to contribute if you can control you communication. if not do me a favor and just use some other real database.

@acarstoiu
Copy link
Author

Well, you and the team have wasted far more time by understanding not what I wrote, but what you think I wrote. Instead of writing your answer in a hurry and the others to cheer you, it would have been far more productive to see that my answer was aimed at this sarcasm:

If you're exposing Elasticsearch to the internet without even this basic protection, then you've already lost.

Also, by real I was referring to the value of the stored data, not to the employed technology. So stay cool, I like Es, but I hate unjustified and unasked for arrogance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/Scripting Scripting abstractions, Painless, and Mustache discuss >enhancement
Projects
None yet
Development

No branches or pull requests

3 participants