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

[RAM] refactors RulesClient.update, by using new Task Manager API bulkUpdateSchedules #134027

Conversation

vitaliidm
Copy link
Contributor

@vitaliidm vitaliidm commented Jun 9, 2022

Summary

When using runNow in scale, there can be situations, when TaskManager capacity is full, thus leading failure of runNow.
Instead, new API bulkUpdateSchedules will be used, which in case if rule schedule is getting updated: will update underlying task schedule and will calculate new runAt time.
More details on new TaskManager API: #132637, #124850

Checklist

vitaliidm added a commit that referenced this pull request Jun 13, 2022
Addresses: #124850
## Summary

- Adds new method Task Manager API `bulkUpdateSchedules`
- Adds calling `taskManager.bulkUpdateSchedules` in rulesClient.bulkEdit to update tasks if updated rules have `scheduleTaskId` property
- Enables the rest of operations for rulesClient.bulkEdit (set schedule, notifyWhen, throttle)
- 
#### bulkUpdateSchedules
Using `bulkUpdatesSchedules` you can instruct TaskManager to update interval of tasks that are in `idle` status.
When interval updated, new `runAt` will be computed and task will be updated with that value

```js
export class Plugin {
  constructor() {
  }

  public setup(core: CoreSetup, plugins: { taskManager }) {
  }

  public start(core: CoreStart, plugins: { taskManager }) {
    try {
      const bulkUpdateResults = await taskManager.bulkUpdateSchedule(
        ['97c2c4e7-d850-11ec-bf95-895ffd19f959', 'a5ee24d1-dce2-11ec-ab8d-cf74da82133d'],
        { interval: '10m' },
      );
      // If no error is thrown, the bulkUpdateSchedule has completed successfully.
      // But some updates of some tasks can be failed, due to OCC 409 conflict for example
    } catch(err: Error) {
      // if error is caught, means the whole method requested has failed and tasks weren't updated
    }    
  }
}
```
### in follow-up PRs
- use  `taskManager.bulkUpdateSchedules` in rulesClient.update (#134027)
- functional test for bulkEdit (#133635)

### Checklist

- [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios

### Release note
Adds new method to Task Manager - bulkUpdatesSchedules, that allow bulk updates of scheduled tasks.
Adds 3 new operations to rulesClient.bulkUpdate: update of schedule, notifyWhen, throttle.
@vitaliidm vitaliidm self-assigned this Jun 13, 2022
@vitaliidm vitaliidm changed the title [RAM]rules client update move to new Task Manager api bulkUpdateSchedules [RAM] refactors rules client update, by using new Task Manager API bulkUpdateSchedules Jun 13, 2022
});

test('updating the alert should not wait for the rerun the task to complete', async () => {
Copy link
Contributor Author

@vitaliidm vitaliidm Jun 13, 2022

Choose a reason for hiding this comment

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

I believe we don't need this test anymore: we not running task anymore right after rule's SO updated, only doing REST API calls.
So, once user updates rule's schedule, there will be no time expensive run of rule, only underlying task update.
In that case, we can wait to this update finished and we won't need to leave unfinished HTTP requests once return response of RulesClient.update

@vitaliidm vitaliidm added technical debt Improvement of the software architecture and operational architecture release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting Feature:Alerting/RulesManagement Issues related to the Rules Management UX v8.4.0 Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) refactoring and removed technical debt Improvement of the software architecture and operational architecture labels Jun 13, 2022
@vitaliidm vitaliidm marked this pull request as ready for review June 13, 2022 17:27
@vitaliidm vitaliidm requested a review from a team as a code owner June 13, 2022 17:27
@elasticmachine
Copy link
Contributor

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

@vitaliidm vitaliidm changed the title [RAM] refactors rules client update, by using new Task Manager API bulkUpdateSchedules [RAM] refactors RulesClient.update, by using new Task Manager API bulkUpdateSchedules Jun 13, 2022
Copy link
Contributor

@ymao1 ymao1 left a comment

Choose a reason for hiding this comment

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

LGTM! Verified that updating a single task from the UI does not run the task immediately but sets a new runAt time for the scheduled task document.

This might be worth a release note since this is a change in behavior for how rule schedule updates work.

);

this.logger.debug(
`Alert update has rescheduled the underlying task: ${updateResult.scheduledTaskId}`
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we include the new runAt in the log message?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Included, thanks for the suggestion

@vitaliidm vitaliidm enabled auto-merge (squash) June 15, 2022 17:57
@vitaliidm vitaliidm merged commit 89de75d into elastic:main Jun 15, 2022
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

✅ unchanged

History

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

cc @vitaliidm

@vitaliidm vitaliidm deleted the repsponse-ops/rules-client-update-move-to-new-taks-manager-api branch March 4, 2024 17:31
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:Alerting/RulesManagement Issues related to the Rules Management UX refactoring 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.4.0
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

5 participants