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

[Response Ops][Task Manager] Adding jest integration test to test capacity based claiming #189431

Merged
merged 10 commits into from
Aug 22, 2024

Conversation

ymao1
Copy link
Contributor

@ymao1 ymao1 commented Jul 29, 2024

Resolves #189111

Summary

Adds jest integration test to test cost capacity based claiming with the mget claim strategy. Using this integration test, we can exclude running other tasks other than our test types. We register a normal cost task and an XL cost task. We test both that we can claim tasks up to 100% capacity and that we will stop claiming tasks if the next task puts us over capacity, even if that means we're leaving capacity on the table.

@ymao1 ymao1 self-assigned this Jul 29, 2024
@ymao1 ymao1 added release_note:skip Skip the PR/issue when compiling release notes Feature:Task Manager Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.16.0 labels Jul 29, 2024

expect(taskRunAtDates.length).toBe(10);

// run at dates should be within a few seconds of each other
Copy link
Contributor Author

Choose a reason for hiding this comment

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

should be within milliseconds, but I'm adding some fudge factor

Copy link
Member

Choose a reason for hiding this comment

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

We shall see how much fudge we will need to apply! :-)

taskStore,
size,
taskPartitioner,
}: OwnershipClaimingOpts): Promise<SearchAvailableTasksResponse> {
const searchedTypes = Array.from(taskTypes)
.concat(Array.from(removedTypes))
.filter((type) => !excludedTypes.has(type));
.filter((type) => !isTaskTypeExcluded(excludedTaskTypes, type));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this allows us to do wildcard exclusions like alerting* instead of specifying the full task type. this is the same as what the default task claimer is doing

Copy link
Member

Choose a reason for hiding this comment

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

thanks for fixing this bug!

@ymao1
Copy link
Contributor Author

ymao1 commented Jul 29, 2024

@elasticmachine merge upstream

@ymao1
Copy link
Contributor Author

ymao1 commented Jul 29, 2024

@elasticmachine merge upstream

@ymao1 ymao1 marked this pull request as ready for review July 29, 2024 23:26
@ymao1 ymao1 requested a review from a team as a code owner July 29, 2024 23:26
@elasticmachine
Copy link
Contributor

Pinging @elastic/response-ops (Team:ResponseOps)

@ymao1
Copy link
Contributor Author

ymao1 commented Jul 30, 2024

Moving back to draft bc we had to revert the original PR

@ymao1 ymao1 marked this pull request as draft July 30, 2024 19:01
@ymao1
Copy link
Contributor Author

ymao1 commented Aug 19, 2024

@elasticmachine merge upstream

unsafe: {
exclude_task_types: flatMap(alphabet, (letter) => [
`${letter}*`,
`${letter.toUpperCase()}*`,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

trying to exclude all task types so the only ones that run are the ones registered in this integration test. I'm prefixing the test task types with _.

Copy link
Member

Choose a reason for hiding this comment

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

Since we're using minimatch, can we just use a simple pattern like: [A-Za-z]* ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that's much better thanks! updated in 2c1ee89

@ymao1 ymao1 marked this pull request as ready for review August 19, 2024 19:39
@ymao1
Copy link
Contributor Author

ymao1 commented Aug 19, 2024

@pmuellr @js-jankisalvi This is ready for review again!

Copy link
Contributor

@js-jankisalvi js-jankisalvi left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@pmuellr pmuellr left a comment

Choose a reason for hiding this comment

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

Sorry for the delay! LGTM, made a suggestion about making the excluded task spec for the test a little simpler (hopefully)

@@ -72,3 +73,13 @@ export function getEmptyClaimOwnershipResult(): ClaimOwnershipResult {
docs: [],
};
}

export function isTaskTypeExcluded(excludedTaskTypes: string[], taskType: string) {
Copy link
Member

Choose a reason for hiding this comment

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

excludedTaskTypes should probably be something like excludedTaskTypePatterns or something, to indicate it has a wildcard aspect

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated in 2c1ee89

unsafe: {
exclude_task_types: flatMap(alphabet, (letter) => [
`${letter}*`,
`${letter.toUpperCase()}*`,
Copy link
Member

Choose a reason for hiding this comment

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

Since we're using minimatch, can we just use a simple pattern like: [A-Za-z]* ?


expect(taskRunAtDates.length).toBe(10);

// run at dates should be within a few seconds of each other
Copy link
Member

Choose a reason for hiding this comment

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

We shall see how much fudge we will need to apply! :-)

taskStore,
size,
taskPartitioner,
}: OwnershipClaimingOpts): Promise<SearchAvailableTasksResponse> {
const searchedTypes = Array.from(taskTypes)
.concat(Array.from(removedTypes))
.filter((type) => !excludedTypes.has(type));
.filter((type) => !isTaskTypeExcluded(excludedTaskTypes, type));
Copy link
Member

Choose a reason for hiding this comment

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

thanks for fixing this bug!

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #29 / Detection Engine - Exception workflows APIs @serverless @serverlessQA @ess rule exceptions execution creating rules with exceptions should be able to execute against an exception list that does include valid case sensitive entries and get back 0 alerts

Metrics [docs]

✅ unchanged

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @ymao1

@ymao1 ymao1 merged commit 9653d7e into elastic:main Aug 22, 2024
39 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Aug 22, 2024
@ymao1 ymao1 deleted the tm-capacity-integration-tests branch August 22, 2024 15:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Task Manager release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.16.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Response Ops][Task Manager] Add more functional tests for resource based task claiming
6 participants