Skip to content
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

Merged
merged 4 commits into from
Sep 6, 2023

Conversation

dvkuznietsov
Copy link
Contributor

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 locally
  • relevant change in docs/ folder
  • covered with integration tests in internal/acceptance
  • relevant acceptance tests are passing
  • using Go SDK

@dvkuznietsov dvkuznietsov requested review from a team as code owners August 29, 2023 19:37
@dvkuznietsov dvkuznietsov requested review from tanmay-db and removed request for a team August 29, 2023 19:37
@codecov-commenter
Copy link

Codecov Report

Merging #2626 (b4ad4b0) into master (cedc1b4) will decrease coverage by 0.02%.
The diff coverage is 62.50%.

Impacted file tree graph

@@            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     
Files Changed Coverage
jobs/resource_job.go 62.50%

@tanmay-db
Copy link
Contributor

Hi, can you mention how you tested this E2E locally?

Comment on lines 582 to 588
job.Settings.RunAs = &JobRunAs{
UserName: job.RunAsUserName,
}
} else {
job.Settings.RunAs = &JobRunAs{
UserName: job.RunAsUserName,
}
Copy link
Contributor

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?

Copy link
Contributor Author

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

@dvkuznietsov
Copy link
Contributor Author

@tanmay-db

Hi, can you mention how you tested this E2E locally?

  • I've built the provider from sources, configured terraform to use the binary and ran terraform apply.
  • then I logged into the workspace and verified the job was created with correct run as
  • then I changed the run as of the job
  • lstly, I ran terraform plan. Terraform detected the drift

@tanmay-db
Copy link
Contributor

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,
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

@dvkuznietsov dvkuznietsov Aug 31, 2023

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

Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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?

Comment on lines +90 to +92
RunAs: &JobRunAs{
UserName: "user@mail.com",
},
Copy link
Contributor

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?

Copy link
Contributor

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?

@dvkuznietsov
Copy link
Contributor Author

@tanmay-db could you re-run integration tests please?

Copy link
Contributor

@tanmay-db tanmay-db left a 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.

@tanmay-db tanmay-db added this pull request to the merge queue Sep 6, 2023
Merged via the queue into databricks:master with commit 55b47c7 Sep 6, 2023
@tanmay-db tanmay-db mentioned this pull request Sep 7, 2023
5 tasks
nkvuong pushed a commit that referenced this pull request Oct 3, 2023
* Detect run_as drift in job resource

* fix SP UUID drift

* suppress_diff for run_as
@alexott
Copy link
Contributor

alexott commented Oct 5, 2023

Opened #2626 to fix it on specific installations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants