timer: add user interfaces for timer framework

[lcwangchao]

What problem does this PR solve?

Issue Number: close #43836

What is changed and how it works?

• Add a new package timer for timer framework
• Add some new interfaces for user
  • Introduce the model TimerRecord to present the meta of the timer
  • Introduce TimerClient to provide some operations of timer for user
  • Introduce Hook for the users to custom actions when timer event is triggered

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• YangKeao
• hawkingrei

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[lcwangchao]

/retest

[hawkingrei]

/review default

[ti-chi-bot]

@hawkingrei:

Summary

• PR Title: timer: add user interfaces for timer framework
• Issue Number: Close #43836
• Diff Size: +2387 -1

The PR introduces a new package timer along with user interfaces to work with timer framework. The following changes are introduced:

1. A new package timer is added for the timer framework.
2. New interfaces for users are created including TimerRecord, TimerClient, and Hook.
3. Unit tests are added for the new package and its features.
4. Changes are made to build/nogo_config.json to include timer code.
5. A new file timer/api/BUILD.bazel has been added.

Potential problems

No potential issues are identified.

Suggestions

It is suggested to add further details in the PR description regarding:

1. The context behind the timer framework, its purpose and the problem it'll resolve.
2. Any changes or refactoring in existing codebase related to the new package and user interfaces.
3. Any future plans related to the project.

In response to this:

/review default

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[lcwangchao]

/retest

[YangKeao]

Good job. Rest LGTM

[YangKeao]

I wonder what's the expected behavior if the client found it's too late to start the job (e.g. if the cluster is down for one or two days.). If they are only expected to execute when the time is within a small offset around the "expected" schedule (e.g. */5 * * * * shouldn't happen at 00:02), a function like "NearestSchedTime" (or other better names) which will return the nearest "expected" schedule time would be really helpful.

The only difference between NearestSchedTime and for-loop with NextEventTime is that the NearestSchedTime can calculate much faster if the timer is regular (e.g. for every 5 seconds). If we don't have this, we'll need to introduce a new range (or limitation) to avoid the "for-loop next" calculates forever, which will also make the expected behavior hard to describe/learn (See the .spec.startingDeadlineSeconds in kubernetes cronjob as a counter example 🤦‍♂️ )

[lcwangchao]

Good catch! I think there is a principle in the framework that there is only one event triggering at the same time. For example, if the timer is set to trigger at the first minute of each hour but the cluster is down for one or two days. When the cluster recovered, there was still only one event triggered even if we have many events after the watermark.

Whether to execute all these jobs or ignore some "expired" depends on the user:

1. If the user wants to execute all passed jobs, he should compute NextEventTime again and again until the returned event time after now.
2. If the user wants to ignore some jobs after a certain time, he can pass that time instead of the watermark to NextEventTime to compute the next event time after it.

When processing one event, a user can submit one or more jobs concurrency, it dependens to him.

[lcwangchao]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 89215c5

[lcwangchao]

/retest