-
Notifications
You must be signed in to change notification settings - Fork 288
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
dm(engine): declarative command should consider time #7640
Conversation
Signed-off-by: lance6716 <lance6716@gmail.com>
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
Codecov Report
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. @@ Coverage Diff @@
## master #7640 +/- ##
================================================
+ Coverage 59.8250% 59.8393% +0.0142%
================================================
Files 812 812
Lines 93078 93014 -64
================================================
- Hits 55684 55659 -25
+ Misses 32541 32512 -29
+ Partials 4853 4843 -10 |
Unit: w.workerType, | ||
Task: w.taskID, | ||
Stage: stage, | ||
StageUpdatedTime: time.Now(), |
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.
Seems this assign tasks no effect
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 prefer to left this one, remove the write to StageUpdatedTime at jobmaster side
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 only update task status when task stage changed, so the StageUpdatedTime may not change for a long time, does this meet user expectations
engine/jobmaster/dm/task_manager.go
Outdated
@@ -115,6 +115,7 @@ func (tm *TaskManager) UpdateTaskStatus(taskStatus runtime.TaskStatus) { | |||
zap.Stringer("unit", taskStatus.Unit), | |||
zap.Uint64("config_modify_revison", taskStatus.CfgModRevision), | |||
) | |||
taskStatus.StageUpdatedTime = time.Now() |
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.
Maybe we can save it somewhere other than taskStatus, so we don't have to add unnecessary properties to TaskStatus and change the unit test
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 prefer Stage and the StageUpdateTime to be together because they have tight relationship, will think about it soon
Signed-off-by: lance6716 <lance6716@gmail.com>
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.
rest LGTM
Unit: w.workerType, | ||
Task: w.taskID, | ||
Stage: stage, | ||
StageUpdatedTime: time.Now(), |
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 only update task status when task stage changed, so the StageUpdatedTime may not change for a long time, does this meet user expectations
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.
LGTM
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 4d74d2f
|
/test-engine-integration-test |
/test-engine-integration-test I'll take a look at failing log |
/test-engine-integration-test |
/run-engine-integration-test |
This pull request has been accepted and is ready to merge. Commit hash: 47759cd
|
/run-all-tests |
/run-engine-integration-test |
Signed-off-by: lance6716 <lance6716@gmail.com>
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 6e5c22c
|
/hold waiting to find a better solution |
Signed-off-by: lance6716 <lance6716@gmail.com>
/run-engine-integration-test ptal @GMHDBJD |
I can say for this time, falling CI should really be a flaky test. The case can be passed in my local PC
|
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.
LGTM
/unhold /merge |
This pull request has been accepted and is ready to merge. Commit hash: d7a67aa
|
/run-all-tests |
/run-verify |
@lance6716: Your PR was out of date, I have automatically updated it for you. At the same time I will also trigger all tests for you: /run-all-tests If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes. 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 ti-community-infra/tichi repository. |
/merge |
failure caused by slow MySQL
|
/run-engine-integration-test |
1 similar comment
/run-engine-integration-test |
Signed-off-by: lance6716 lance6716@gmail.com
What problem does this PR solve?
Issue Number: ref #4287
What is changed and how it works?
If the running "error" stage is updated after expected "running" stage, we skip action.
Check List
Tests
Questions
Will it cause performance regression or break compatibility?
Do you need to update user documentation, design documentation or monitoring documentation?
Release note