-
Notifications
You must be signed in to change notification settings - Fork 409
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
Detect run_as drift in job resource #2626
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2626 +/- ##
==========================================
- Coverage 86.77% 86.76% -0.02%
==========================================
Files 146 146
Lines 12655 12663 +8
==========================================
+ Hits 10982 10987 +5
- Misses 1108 1110 +2
- Partials 565 566 +1
|
Hi, can you mention how you tested this E2E locally? |
jobs/resource_job.go
Outdated
job.Settings.RunAs = &JobRunAs{ | ||
UserName: job.RunAsUserName, | ||
} | ||
} else { | ||
job.Settings.RunAs = &JobRunAs{ | ||
UserName: job.RunAsUserName, | ||
} |
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.
Both the statements in if else is same?
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.
sorry, didn't push the latest commit
|
I have triggered an integration test run. Please wait until it's finished before this can be merged. |
} | ||
} else { | ||
job.Settings.RunAs = &JobRunAs{ | ||
ServicePrincipalName: job.RunAsUserName, |
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.
@dvkuznietsov Two questions:
- Is it certain that if a job is not userEmail then it is service principal?
- Is checking for @ for email enough?
Hi @nkvuong, do you know if there is some existing utility for checking valid email in terraform?
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.
Is it certain that if a job is not userEmail then it is service principal?
Is checking for @ for email enough?
as of now, run_as_user_name is either an email or a UUID. String parsing is not ideal and that's why we moved on to run_as field in write path, but that's what we work with for 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.
and, to answer your question, I beleive that's enough
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.
@dvkuznietsov is it too much to ask the Jobs API to use run_as for reads and writes rather than force clients to do this mapping themselves? Thinking RESTfully, when a user sets a field on a resource, they would expect to get that field as they set it when getting that resource back. However, here, Jobs may be breaking that pattern. WDYT?
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.
@mgyucht the fields are not symmetric: run_as is an optional field that we have recently added and run_as_user_name is an old field that is almost always filled in.
The intention for this change is if users don't provide run_as, we don't need to catch drifts in run_as_user_name, but if they do provide it, we do need to detect drifts in run_as_user_name
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.
Can you include run_as
in the get response though? I guess what I don't understand is why it is a write-only field.
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 can't. It would be a breaking change for customers that pipe GET responses to create/reset calls
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.
Forgive me for asking, but why would that be a breaking change? Does the Jobs API not tolerate both of these parameters being set at the same time in a create/reset call?
RunAs: &JobRunAs{ | ||
UserName: "user@mail.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.
I thought RunAs is not included in get requests?
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.
Just to confirm @dvkuznietsov what was the conclusion on these comments? I am guessing these were discussed offline?
@tanmay-db could you re-run integration tests please? |
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, unrelated integration tests are failing and shouldn't be a blocker for this.
* Detect run_as drift in job resource * fix SP UUID drift * suppress_diff for run_as
Opened #2626 to fix it on specific installations |
Changes
run_as field in jobs is asymmetric: it's JobSettings.RunAs in create/update requests and RunAsUserName in read requests. As a result, when the job drifts, terraform can't detect the drift. To fix that, adjust the Read function in terraform to fill in the RunAs struct based on the RunAsUsername field.
Tests
Tested locally E2E
make test
run locallydocs/
folderinternal/acceptance