Initial EQL rest API implementation#49768
Conversation
There was a problem hiding this comment.
was not sure if there is a better approach instead of this ^
There was a problem hiding this comment.
I am not sure we need this here. I don't see a scenario when we are going to resolve the index name based on the content of the request itself.
There was a problem hiding this comment.
Removing this change, replacing with more suitable solution after discussion with Igor.
a32e29a to
bcf861b
Compare
There was a problem hiding this comment.
A possible fix for equals as a separate commit here, can remove if not appropriate or should be it's own separate PR.
Sharing the same SearchHit structures in the eql resful API implementation, and the equality checks would fail without this change in place.
Following the same thing that was done a line below with highlightFields accessors.
There was a problem hiding this comment.
It might be a bit cleaner to make this a separate PR to master and 7.x and then merge it in. In any case, I think this requires a modification to SearchHitTests that would trigger the issue that you are trying to fix here.
There was a problem hiding this comment.
Sounds good, will update this PR once this change goes through the master.
There was a problem hiding this comment.
This file change is removed now from PR.
b883229 to
350ad30
Compare
|
4bf928c to
4fef4a2
Compare
|
Pulled the latest master to feature/eql and rebased my PR against it, cause of build failures due to java version master branch was on Java 13 already |
4fef4a2 to
9376e86
Compare
|
Pinging @elastic/es-search (:Search/EQL) |
imotov
left a comment
There was a problem hiding this comment.
Should we also add a rest client and add some rest level tests to make sure it works end-to-end?
| public class EqlPlugin extends Plugin implements ActionPlugin { | ||
| @Override | ||
| public List<ActionHandler<? extends ActionRequest, ? extends ActionResponse>> getActions() { | ||
| return Arrays.asList( |
There was a problem hiding this comment.
We can probably replace it with Collections.singletonList() here and below since we don't anticipate more actions here.
There was a problem hiding this comment.
Thought there was a possibility of one more "translate" action down the road.
|
|
||
| @Override | ||
| public ActionRequestValidationException validate() { | ||
| return null; |
There was a problem hiding this comment.
Since we rely on the fact that index, timestampField, eventTypeField, etc cannot be null and fetchSize cannot be negative, we should validate that it's indeed the case. We could also make serialization more forgiving and avoid serializing the same default values on every request.
There was a problem hiding this comment.
Will add validation code
There was a problem hiding this comment.
I am not sure we need this here. I don't see a scenario when we are going to resolve the index name based on the content of the request itself.
| // Not sure yet if we will always have index in the path or not | ||
| // TODO: finalize the endpoints | ||
| controller.registerHandler(GET, "/{index}/_eql/search", this); | ||
| controller.registerHandler(GET, "/_eql/search", this); |
There was a problem hiding this comment.
In most cases, if the index name is not specified on the URL we search all indices or use index specified inside the request. In this case I don't think we will ever search all indices and I don't see any provisions from specifying the index name inside the request. So, I think we can remove this version.
There was a problem hiding this comment.
Yeah, there was like going back-n-forth on this, so included both versions. Will remove the latter.
| * like everything else. We want to stick as closely as possible to | ||
| * Elasticsearch's defaults though, while still layering in ways to | ||
| * control the output more easilly. | ||
| * control the output more easily. |
There was a problem hiding this comment.
I would move this file into a separate trivial PR.
There was a problem hiding this comment.
Will revert this file change from this PR.
|
@elasticmachine run elasticsearch-ci/1 |
It's my first PR, need a bit of feedback on the code shape and direction.
Specifically had to poke through RBACEngine.java and “mark” the request with CompositeIndicesRequest interface, not sure if this is the right approach.