-
Notifications
You must be signed in to change notification settings - Fork 2k
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
job region defaults to node region #6064
Conversation
api/jobs.go
Outdated
@@ -704,7 +704,7 @@ func (j *Job) Canonicalize() { | |||
j.Stop = boolToPtr(false) | |||
} | |||
if j.Region == nil { | |||
j.Region = stringToPtr("global") | |||
j.Region = stringToPtr("") |
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.
This breaks all the canonicalize tests and seems like the wrong thing to do. Canonicalize should continue to use "global" as the region if its not set.
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.
This should be set to a sentinel value that indicates region was not provided and canonicalized. Changing this means I will have to change all the tests tho
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 think we ultimately decided to leave canonicalization alone but changing the way jobUpdate sets defaults. Or do I still canonicalize to a sentienl value? cc @schmichael @angrycub
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.
Good question. I'm leaning toward leaving canonicalization alone if for no other reason than backwards compatibility.
The job submission code can do the proper default for Job.Region and avoid this code taking effect entirely.
More detailed ramblings we can ignore for now:
I think this is ready if someone could give it a final look over |
Code looks good, the only thing that looks weird to me is
not going to the HCL region? |
Great question @endocrimes, I think it should go to the HCL, but I will add more tests to confirm that behavior. |
For this case:
I think this test already confirms that behavior, but I forgot to add it to the truth table in this PR description UPDATE: updated truth table w/ what I think is the desired behavior |
for this case:
I think that is the intended behavior because http needs to take precedence over hcl. So if a user specifies "global" at the command line arg, they are expecting it to go to a region that corresponds to whatever "global" means. However, if that is incorrect then my understanding of what should take precedence is also incorrect. I think the main issue this PR is trying to address is when both hcl and http are nil, so I am not sure what the correct precedence is if global is explicitly specified in the http. |
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 going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
Overview
PR #5664 changed behavior to default to a region called "global", when it should default to the region of the node it's submitting the job to.
Behavior
Hcl Region := Region specified in the Job hcl config
Http Region := Region specified as a
region
query parameter in the http request to the command agent (so either via a script or usually a command line argument)Http Region takes precedence over Hcl Region
"global" Region value defaults to region of the node you're submitting to
Implementation
While working on PR #5664 we discovered that the Hcl region gets saved but ignored, as downstream RPC calls only reference the region provided in the WriteRequest in the JobRegisterRequest, which used to come from the Http Region. This means that the Job state and the JobRegisterRequest regions became decoupled, which I fixed in previous PR.
However, that actually broke the correct behavior because there is further canonicalization that happens to the WriteRequest, which sets Region to the node region if not present:
https://github.com/hashicorp/nomad/blob/master/command/agent/job_endpoint.go#L405
https://github.com/hashicorp/nomad/blob/master/command/agent/http.go#L472
https://github.com/hashicorp/nomad/blob/master/command/agent/http.go#L431-L438
(thus, if Http Region is nil, but a user set "global" in the Hcl, the Hcl "global" value would get saved but ignored and the actual Region value for the job would get configured to the node region)
Discussion