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
Execute EnrichPolicyRunner on a non dedicated master node. #76881
Execute EnrichPolicyRunner on a non dedicated master node. #76881
Conversation
9b45d01
to
dd73f02
Compare
Introduce an internal action that the execute policy action delegates to. This to ensure that the actual policy execution is never executed on the elected master node or dedicated master nodes. In case the cluster consists out of a single node then the internal action will attempt to execute on the current/local node. The actual enrich policy execution is encapsulated in the `EnrichPolicyRunner` class. This class manages the execution of several API calls, so this itself isn't doing anything heavy. However the coordination of these api calls (in particular the reindex api call) may involve some non-neglectable work/overhead and this shouldn't be performed on the elected master or any other dedicated master node. Closes elastic#70436
dd73f02
to
5d7a948
Compare
Pinging @elastic/es-core-features (Team:Core/Features) |
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.
General structure and test coverage LGTM. I'm less familiar with the nitty-gritty of tasks but would be interested in more info on that at some point.
.../enrich/src/main/java/org/elasticsearch/xpack/enrich/action/InternalExecutePolicyAction.java
Outdated
Show resolved
Hide resolved
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.
Some questions regarding order of locking/unlocking policies. I like the idea here, but I think the policy locking/unlocking is tricky, especially with waitForComplete=false
.../enrich/src/main/java/org/elasticsearch/xpack/enrich/action/InternalExecutePolicyAction.java
Outdated
Show resolved
Hide resolved
.../enrich/src/main/java/org/elasticsearch/xpack/enrich/action/InternalExecutePolicyAction.java
Show resolved
Hide resolved
.../enrich/src/main/java/org/elasticsearch/xpack/enrich/action/InternalExecutePolicyAction.java
Outdated
Show resolved
Hide resolved
.../enrich/src/main/java/org/elasticsearch/xpack/enrich/action/InternalExecutePolicyAction.java
Show resolved
Hide resolved
…runner_to_non_dedicated_master_node
… response but not release the policy immediately. Execute get task request with wait_for_completion=true and when that returns release the policy.
…runner_to_non_dedicated_master_node
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.
Thanks @martijnvg, LGTM!
Backporting elastic#76881 to 7.x branch. Introduce an internal action that the execute policy action delegates to. This to ensure that the actual policy execution is never executed on the elected master node or dedicated master nodes. In case the cluster consists out of a single node then the internal action will attempt to execute on the current/local node. The actual enrich policy execution is encapsulated in the `EnrichPolicyRunner` class. This class manages the execution of several API calls, so this itself isn't doing anything heavy. However the coordination of these api calls (in particular the reindex api call) may involve some non-neglectable work/overhead and this shouldn't be performed on the elected master or any other dedicated master node. Closes elastic#70436
Backporting elastic#76881 to 7.x branch. Introduce an internal action that the execute policy action delegates to. This to ensure that the actual policy execution is never executed on the elected master node or dedicated master nodes. In case the cluster consists out of a single node then the internal action will attempt to execute on the current/local node. The actual enrich policy execution is encapsulated in the `EnrichPolicyRunner` class. This class manages the execution of several API calls, so this itself isn't doing anything heavy. However the coordination of these api calls (in particular the reindex api call) may involve some non-neglectable work/overhead and this shouldn't be performed on the elected master or any other dedicated master node. Closes elastic#70436
Backporting elastic#76881 to 7.15 branch. Introduce an internal action that the execute policy action delegates to. This to ensure that the actual policy execution is never executed on the elected master node or dedicated master nodes. In case the cluster consists out of a single node then the internal action will attempt to execute on the current/local node. The actual enrich policy execution is encapsulated in the `EnrichPolicyRunner` class. This class manages the execution of several API calls, so this itself isn't doing anything heavy. However the coordination of these api calls (in particular the reindex api call) may involve some non-neglectable work/overhead and this shouldn't be performed on the elected master or any other dedicated master node. Closes elastic#70436
Backporting #76881 to 7.15 branch. Introduce an internal action that the execute policy action delegates to. This to ensure that the actual policy execution is never executed on the elected master node or dedicated master nodes. In case the cluster consists out of a single node then the internal action will attempt to execute on the current/local node. The actual enrich policy execution is encapsulated in the `EnrichPolicyRunner` class. This class manages the execution of several API calls, so this itself isn't doing anything heavy. However the coordination of these api calls (in particular the reindex api call) may involve some non-neglectable work/overhead and this shouldn't be performed on the elected master or any other dedicated master node. Closes #70436
Backporting #76881 to 7.x branch. Introduce an internal action that the execute policy action delegates to. This to ensure that the actual policy execution is never executed on the elected master node or dedicated master nodes. In case the cluster consists out of a single node then the internal action will attempt to execute on the current/local node. The actual enrich policy execution is encapsulated in the `EnrichPolicyRunner` class. This class manages the execution of several API calls, so this itself isn't doing anything heavy. However the coordination of these api calls (in particular the reindex api call) may involve some non-neglectable work/overhead and this shouldn't be performed on the elected master or any other dedicated master node. Closes #70436
In case a cluster consists out of multiple nodes then delegate the execution of EnrichPolicyRunner
to a node that is not the elected master and nodes that are not dedicated master.
Closes #70436