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

Store indexed scripts in the cluster state instead of the .scripts index #17650

Merged
merged 1 commit into from
Apr 22, 2016

Conversation

martijnvg
Copy link
Member

@martijnvg martijnvg commented Apr 11, 2016

This PR also cleans up the cyclic dependency ScriptService has at the moment. By moving scripts to the cluster state, the Client dependency was no longer needed.

Open questions:

  • How to deal with scripts already stored in the .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?
  • The script.indexed.* settings haven't been renamed yet to script.stored.*. Are we okay with making a hard break here? Or do we want to deprecate script.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

@martijnvg
Copy link
Member Author

I also added a soft limit for scripts based on @colings86 suggestion.

@martijnvg
Copy link
Member Author

The script.indexed.* settings haven't been renamed yet to script.stored.. Are we okay with making a hard break here? Or do we want to deprecate script.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)

A node will not start if there are unknown settings, so during upgrading or test driving 5.x this will bubble up quickly.

@martijnvg martijnvg force-pushed the stored_scripts branch 5 times, most recently from e9e58a7 to 9e5c5fa Compare April 18, 2016 15:47
@clintongormley
Copy link

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));
Copy link
Contributor

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?

Copy link
Contributor

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

@colings86
Copy link
Contributor

@martijnvg I left a couple of consistency comments but otherwise I think it looks good.

@martijnvg martijnvg force-pushed the stored_scripts branch 2 times, most recently from a6157bd to 685c95c Compare April 20, 2016 12:46
@martijnvg
Copy link
Member Author

@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'])
-----------------------------------
Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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.
Copy link
Contributor

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?

@colings86
Copy link
Contributor

@martijnvg I left some more comments but I think its very close

@martijnvg
Copy link
Member Author

@colings86 I've updated the PR and addressed your comments.

@colings86
Copy link
Contributor

LGTM

…the `.scripts` index.

Also added max script size soft limit for stored scripts.

Closes elastic#16651
builder.copyCurrentStructure(parser);
}
break;
case "template":
Copy link
Contributor

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":
.....

Copy link
Member Author

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

@Mpdreamz
Copy link
Member

Mpdreamz commented May 1, 2016

@martijnvg small request the current exception message when es.script.indexed=true is passed is:

System.Exception: Exception in thread "main" java.lang.IllegalArgumentException: unknown setting [script.indexed] did you mean any of [script.inline, script.ingest]?

Where es.script.stored=true is the more logical equivalent to suggest (this of the latest snapshot, have not tested HEAD of master).

@clintongormley
Copy link

@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 script.indexed is used to recommend script.stored instead.

@martijnvg
Copy link
Member Author

@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.

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

Successfully merging this pull request may close these issues.

6 participants