-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Store indexed scripts in the cluster state instead of the .scripts
index
#17650
Conversation
8322b8e
to
816f53a
Compare
10b8a32
to
89b0adc
Compare
I also added a soft limit for scripts based on @colings86 suggestion. |
A node will not start if there are unknown settings, so during upgrading or test driving 5.x this will bubble up quickly. |
e9e58a7
to
9e5c5fa
Compare
i'm OK with a hard break here, as long as we provide a utility that the user can run to move scripts from indexed to stored. This could even be a shell script that the user can copy and paste from the migration docs. |
public void handleRequest(final RestRequest request, final RestChannel channel, Client client) { | ||
PutStoredScriptRequest putRequest = new PutStoredScriptRequest(getScriptLang(request), request.param("id")); | ||
putRequest.script(request.content()); | ||
client.admin().cluster().putStoredScript(putRequest, new AcknowledgedRestListener<>(channel)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these Rest Actions not forward the request to the Transport Actions so that we make sure that are always handled in the same way? I thought in general the rest actions usually forward to the transport actions so the REST API and Java API are guaranteed to work the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, ignore this, the rest actions are actually just forwarding to the transport actions
@martijnvg I left a couple of consistency comments but otherwise I think it looks good. |
a6157bd
to
685c95c
Compare
@colings86 I've addressed your comment and added docs. |
|
||
for doc in helpers.scan(es, index=".scripts", preserve_order=True): | ||
es.put_script(lang=doc['_type'], id=doc['_id'], body=doc['_source']) | ||
----------------------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@honzakral Would you like to verify if this script is okay? I did need to add preserve_order=True
, otherwise the scan helper would fail, because it uses search_type=scan
which has been removed in 5.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will do an updated version of the client for 5.0 where I will replace the search_type=scan
with sort: _doc
- it's already implemented in master
so no need for it here.
Otherwise LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx, I will check if the script snippet without preserve_order=True
.
|
||
The response should include all your scripts from the `.scripts` index. | ||
After you have verified that all your scripts have been moved, optionally as a last step, | ||
you can delete the `.scripts` index as Elasticsearch no longer uses it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be a good idea to add a note to the Java API section of the breaking changes doc meantioning the change of method names in the client from IndexScripts to StoredScripts?
@martijnvg I left some more comments but I think its very close |
@colings86 I've updated the PR and addressed your comments. |
LGTM |
54b3261
to
885c154
Compare
…the `.scripts` index. Also added max script size soft limit for stored scripts. Closes elastic#16651
885c154
to
c5ad2e2
Compare
builder.copyCurrentStructure(parser); | ||
} | ||
break; | ||
case "template": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bodies in both cases are the same, why not write just:
case "script":
case "template":
.....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. It has been removed: 22dc06f
@martijnvg small request the current exception message when
Where |
@Mpdreamz yeah i had this as well, it's because of the fuzzy matching we're using on incorrect settings. That said, I think we should add a hardcoded rule when |
@Mpdreamz @clintongormley I like the idea of a hard coded rule, but there is no infrastructure for that. Adding that doesn't seem to be worth the effort for this breaking change. |
This PR also cleans up the cyclic dependency
ScriptService
has at the moment. By moving scripts to the cluster state, theClient
dependency was no longer needed.Open questions:
.scripts
index? Do we want to provide support for moving indexed scripts to the cluster state? Upon upgrading to 5.x the.scripts
index will not be removed. We can provide a script that can be executed just after the upgrade. Or do we want to provide something that automatically moves scripts from the.script
index to the cluster state, if so how?script.indexed.*
settings haven't been renamed yet toscript.stored.*
. Are we okay with making a hard break here? Or do we want to deprecatescript.indexed.*
settings first. How everything is coded right now this doesn't seem to be straight forward.(ScriptType.INDEXED enum has been renamed, but not its script type parameter)
PR for #16651