-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
HLRC: Add get rollup job #33921
HLRC: Add get rollup job #33921
Conversation
Adds support for the get rollup job to the High Level REST Client. I had to do two interesting and unexpected things: 1. I ported the rollup state wiping code into the high level client tests. I'll move this into the test framework in a followup and remove the x-pack version. 2. The `timeout` in the rollup config was serialized using the `toString` representation of `TimeValue` which produces fractional time values which are more human readable but aren't supported by parsing. So I switched it to `getStringRep`.
Pinging @elastic/es-core-infra |
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.
Just the little bit about the test and toXContent.
* @param jobId id of the job to return or {@code _all} to return all jobs | ||
*/ | ||
public GetRollupJobRequest(final String jobId) { | ||
this.jobId = Objects.requireNonNull(jobId, "jobId is required"); |
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.
<3 validation here
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.
The server-side request (and REST endpoint) converts null, empty or *
into _all
. So we should probably do the same here, or remove that from the server-side request and add the logic to the transport action.
Otherwise an asterisk from the HLRC will go unconverted and the server will try to look for a job literally named *
:)
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.
It looks like REST doesn't support null but the transport client does. Or maybe I'm reading it wrong. I'm not sure we need all of that because we have a "normal" way to query for all.
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.
We could totally do a default constructor that sets it to _all
and ensure this one does not do that behavior w the null check
* is also persistent when changing from started/stopped in case the allocated | ||
* task is restarted elsewhere. | ||
*/ | ||
public enum IndexerState { |
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.
is this only valid in the context of a rollup job response? if not, can u make it so others can use it by making its own class.
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 believe it is only valid for this, yes.
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.
++ This is correct, atm only exposed to the user via the GetJob API
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.
👍
} | ||
|
||
@Override | ||
public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException { |
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.
hey, these toXContent are not needed in responses. They help with the tests but you can manually create a parser for now, as I have to think about how to better do these tests without putting the toXContent logic in the classes themselves.
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.
KK. I'll pull.
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.
Doesn't this make testing a lot harder than just implementing a manual parser? E.g. we can't use AbstractXContentTestCase
anymore, which does all the xcontent shuffling serializing/reparsing/equivalence checks?
Requires a refactor to AbstractXContentTestCase
Also pulls in the rollup cleaning from elastic#33921
assertEquals(putRollupJobRequest.getConfig(), job.getJob()); | ||
assertThat(job.getStats().getNumPages(), lessThan(10L)); | ||
assertEquals(numDocs, job.getStats().getNumDocuments()); | ||
assertThat(job.getStats().getNumInvocations(), lessThan(10L)); |
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.
Hmm, i wonder if this is potentially flaky? E.g. the job is configured to trigger every second, so if it takes longer than 10 seconds to get to this point for whatever reason, the assertion might fail.
I think the other assertions are fine since they should be deterministic (number of docs indexed, number of pages, etc)
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.
Got it. I hadn't realized it'd count time when it didn't do any work. I'll just assert >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.
Yeah, it's not necessarily time... but it increments each time the indexer is "triggered", even if nothing is done after the trigger. Handy way to help debug if the indexer is "doing things" even if no documents are being emitted for some reason.
assertEquals(numDocs, job.getStats().getNumDocuments()); | ||
assertThat(job.getStats().getNumInvocations(), lessThan(10L)); | ||
assertEquals(1, job.getStats().getOutputDocuments()); | ||
assertEquals(IndexerState.STARTED, job.getStatus().getState()); |
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.
Probably need to check for either STARTED
or INDEXING
since you could catch the job right after it triggers but before it realizes there's no more data to index
|
||
public void testGetJob() { | ||
boolean getAll = randomBoolean(); | ||
String job = getAll ? "_all" : RequestConvertersTests.randomIndicesNames(1, 1)[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.
Related to above comment about null/empty/asterisk... if that changes we should probably include those as options here too
Left a few minor comments/questions about the rollup'y bits :) |
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.
ty, i think i will start showing the response test to people as the proper way to do it :)
❤️ Maybe we can build something simpler to use once we have a few examples using it? |
Adds support for the get rollup job to the High Level REST Client. I had to do three interesting and unexpected things: 1. I ported the rollup state wiping code into the high level client tests. I'll move this into the test framework in a followup and remove the x-pack version. 2. The `timeout` in the rollup config was serialized using the `toString` representation of `TimeValue` which produces fractional time values which are more human readable but aren't supported by parsing. So I switched it to `getStringRep`. 3. Refactor the xcontent round trip testing utilities so we can test parsing of classes that don't implements `ToXContent`.
Adds support for the get rollup job to the High Level REST Client. I had to do three interesting and unexpected things: 1. I ported the rollup state wiping code into the high level client tests. I'll move this into the test framework in a followup and remove the x-pack version. 2. The `timeout` in the rollup config was serialized using the `toString` representation of `TimeValue` which produces fractional time values which are more human readable but aren't supported by parsing. So I switched it to `getStringRep`. 3. Refactor the xcontent round trip testing utilities so we can test parsing of classes that don't implements `ToXContent`.
Adds support for the get rollup job to the High Level REST Client. I had
to do two interesting and unexpected things:
tests. I'll move this into the test framework in a followup and remove
the x-pack version.
timeout
in the rollup config was serialized using thetoString
representation ofTimeValue
which produces fractional timevalues which are more human readable but aren't supported by parsing. So
I switched it to
getStringRep
.