Fixed data job status in case of OOM #1586
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
antoniivanov
reviewed
Feb 2, 2023
...c/integration-test/java/com/vmware/taurus/datajobs/it/common/DataJobDeploymentExtension.java
Show resolved
Hide resolved
...es_control_service/src/integration-test/java/com/vmware/taurus/datajobs/it/DataJobOOMIT.java
Show resolved
Hide resolved
dakodakov
approved these changes
Feb 3, 2023
antoniivanov
approved these changes
Feb 3, 2023
mivanov1988
added a commit
that referenced
this pull request
May 22, 2023
Why We recently got the following feedback from our internal client: A data job was listed as successful even though it hit the 12 hour limit and was killed; the logs do not show that either - the last entry in the log just shows the last object that was sent for ingestion, but there is no summary of the data job. The problem is caused by the following fix - #1586. When the job hit the 12-hour limit the K8S Pod is terminated and we construct partial JobExecutionStatus which enters in the following if statement and returns Optional.empty() rather than the constructed object. https://github.com/vmware/versatile-data-kit/blob/4763ba877f43b270fbd4770bc1533216f7c5d618/projects/control-service/projects/pipelines_control_service/src/main/java/com/vmware/taurus/service/KubernetesService.java#L1656 As a result, this job execution becomes stuck in the Running status until it is detected by emergency logic, which marks such executions as successful due to the lack of associated Pods to them. What Added validation for an already completed job in a more appropriate place. Testing Done Added integration test Signed-off-by: Miroslav Ivanov miroslavi@vmware.com
mivanov1988
added a commit
that referenced
this pull request
May 23, 2023
Why We recently got the following feedback from our internal client: A data job was listed as successful even though it hit the 12 hour limit and was killed; the logs do not show that either - the last entry in the log just shows the last object that was sent for ingestion, but there is no summary of the data job. The problem is caused by the following fix - #1586. When the job hit the 12-hour limit the K8S Pod is terminated and we construct partial JobExecutionStatus which enters in the following if statement and returns Optional.empty() rather than the constructed object. https://github.com/vmware/versatile-data-kit/blob/4763ba877f43b270fbd4770bc1533216f7c5d618/projects/control-service/projects/pipelines_control_service/src/main/java/com/vmware/taurus/service/KubernetesService.java#L1656 As a result, this job execution becomes stuck in the Running status until it is detected by emergency logic, which marks such executions as successful due to the lack of associated Pods to them. What Added validation for an already completed job in a more appropriate place. Testing Done Added integration test Signed-off-by: Miroslav Ivanov miroslavi@vmware.com
mivanov1988
added a commit
that referenced
this pull request
May 25, 2023
# Why We recently got the following feedback from our internal client: A data job was listed as successful even though it hit the 12 hour limit and was killed; the logs do not show that either - the last entry in the log just shows the last object that was sent for ingestion, but there is no summary of the data job. The problem is caused by the following fix - #1586. When the job hit the 12-hour limit the K8S Pod is terminated and we construct partial JobExecutionStatus which enters in the following if statement and returns Optional.empty() rather than the constructed object. https://github.com/vmware/versatile-data-kit/blob/4763ba877f43b270fbd4770bc1533216f7c5d618/projects/control-service/projects/pipelines_control_service/src/main/java/com/vmware/taurus/service/KubernetesService.java#L1656 As a result, this job execution becomes stuck in the Running status until it is detected by emergency logic, which marks such executions as successful due to the lack of associated Pods to them. # What Added validation for an already completed job in a more appropriate place. # Testing Done Added integration test Signed-off-by: Miroslav Ivanov miroslavi@vmware.com --------- Signed-off-by: Miroslav Ivanov miroslavi@vmware.com Co-authored-by: github-actions <>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why
Currently, in the case of Data Job failure caused by OOM, the Control Services marks the data job with User Error but after some time it overrides the status to Platform Error. This is caused by K8S Job events that come after the data job completion. They don't contain enough data and the Control Service treats them as Platform Errors.
Log of the data job execution:
What
Implemented a logic wich omits events that come after the Data Job completion.
Testing done
Introduced integration test.
Signed-off-by: Miroslav Ivanov miroslavi@vmware.com