-
Notifications
You must be signed in to change notification settings - Fork 366
[AN-557] Include VM initialization time in cost calculation for Batch jobs #7744
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
Conversation
val endedRegex = ".*RUNNING to.*".r // can be SUCCEEDED or FAILED | ||
// on Batch, when job transitions to SCHEDULED state it indicates that the VM is being initialized. Users are billed for this | ||
// startup time. Hence, the 'vmStartTime' corresponds to when the job enters the SCHEDULED state. | ||
val startedRegex = ".*QUEUED to SCHEDULED.*".r |
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.
Any chance we might be transitioning to scheduled from a state other than QUEUED?
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.
My understanding from conversation with Batch team was that SCHEDULED only happens after QUEUED.
It seems the only other state that can exist before QUEUED is STATE_UNSPECIFIED
but I am not sure if job can go from STATE_UNSPECIFIED -> SCHEDULED 🤔
https://cloud.google.com/batch/docs/reference/rest/v1/projects.locations.jobs#State
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.
Do we want the start regex to be ".*to SCHEDULED.*"
to be safe?
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.
That does seem a little safer, but I'm good either way based on your previous comment.
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 will update the regex just to be safe. The important part here is reaching the SCHEDULED state which would be achieved by ".*to SCHEDULED.*"
as well.
@@ -238,13 +251,44 @@ class BatchRequestExecutorSpec | |||
result.status match { | |||
case RunStatus.Failed(_, events, _) => | |||
val eventNames = events.map(_.name) | |||
val eventTimes = events.map(_.offsetDateTime.toString) | |||
println(eventNames) |
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'm guessing this is a debug line that should be removed?
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.
Yes. Maybe this is a leftover from previous PR. The test do succeed without the println.
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.
Oh, yes, right, I got confused and though it was being added here 🤦♀️
Description
Jira: https://broadworkbench.atlassian.net/browse/AN-557
This PR attempts to fix the underestimation of cost for Batch jobs. On Batch, users incur cost when VM is being initialized. Hence use corresponding events for
vmStartTime
andvmEndTime
for cost calculations.Events for a job run locally:

vmStartTime
now corresponds to SCHEDULED state:Release Notes Confirmation
CHANGELOG.md
CHANGELOG.md
in this PRCHANGELOG.md
because it doesn't impact community usersTerra Release Notes