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

HLRC: Add get rollup job #33921

Merged
merged 10 commits into from
Oct 2, 2018
Merged

HLRC: Add get rollup job #33921

merged 10 commits into from
Oct 2, 2018

Conversation

nik9000
Copy link
Member

@nik9000 nik9000 commented Sep 20, 2018

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.

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`.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

Copy link
Contributor

@hub-cap hub-cap left a 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");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<3 validation here

Copy link
Contributor

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 * :)

Copy link
Member Author

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.

Copy link
Contributor

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

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.

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Contributor

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

KK. I'll pull.

Copy link
Contributor

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?

polyfractal added a commit to polyfractal/elasticsearch that referenced this pull request Sep 24, 2018
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));
Copy link
Contributor

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)

Copy link
Member Author

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.

Copy link
Contributor

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

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

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

@polyfractal
Copy link
Contributor

Left a few minor comments/questions about the rollup'y bits :)

Copy link
Contributor

@hub-cap hub-cap left a 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 :)

@nik9000
Copy link
Member Author

nik9000 commented Sep 28, 2018

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?

@nik9000 nik9000 merged commit f904c41 into elastic:master Oct 2, 2018
nik9000 added a commit that referenced this pull request Oct 2, 2018
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`.
kcm pushed a commit that referenced this pull request Oct 30, 2018
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`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants