Use resource.yml in field classification in config-remote-sync#4677
Use resource.yml in field classification in config-remote-sync#4677ilyakuz-db wants to merge 6 commits intomainfrom
resource.yml in field classification in config-remote-sync#4677Conversation
|
Commit: 7957b55
15 interesting tests: 7 SKIP, 6 RECOVERED, 2 flaky
Top 36 slowest tests (at least 2 minutes):
|
| email_notifications.on_failure[0]: replace | ||
| max_concurrent_runs: replace | ||
| tags['env']: remove | ||
| timeout_seconds: remove |
There was a problem hiding this comment.
This is expected, logic was incorrect previously - this case was skipped completely
| // If a CLI-defaulted field is changed on remote and should be disabled | ||
| // (e.g. queueing disabled → remote field is nil), we can't define it | ||
| // in the config as "null" because the CLI default will be applied again. | ||
| var resetValues = map[string][]resetRule{ |
There was a problem hiding this comment.
Should we include this logic in resources.yml?
| reason: managed | ||
|
|
||
| backend_defaults: | ||
| # Backend returns PERFORMANCE_OPTIMIZED for serverless jobs when not set |
There was a problem hiding this comment.
This is set only for serverless jobs, probably, this should live in changes desc overrides
There was a problem hiding this comment.
Is this field ever set for non-serverless jobs?
|
|
||
| # Same as clusters.node_type_id — see clusters/resource_cluster.go#L333 | ||
| # s.SchemaPath("node_type_id").SetComputed() | ||
| - field: tasks[*].new_cluster.node_type_id |
There was a problem hiding this comment.
When I try to create new_cluster without node_type_id it fails with 400 error:
Endpoint: POST https://<host>/api/2.2/jobs/reset
HTTP Status: 400 Bad Request
API error_code: INVALID_PARAMETER_VALUE
API message: Cluster validation error: Unknown node type id
Considering that backend default is applied only when config value is nil, and for nil value we have 400 error - it doesn't make sense to keep it here
There was a problem hiding this comment.
Question, if I don't specify new_cluster, can it be added by the backend when resource is fetched? I guess not, or some test would fail, but good to say it explicitly.
resource.yml in field classification in config-remote-sync
| ignore_remote_changes: | ||
| # edit_mode is set by CLI, not user-configurable | ||
| - field: edit_mode | ||
| reason: managed |
There was a problem hiding this comment.
I'm using "managed" in other places to mean managed by backend, we should have another reason here.
|
|
||
| jobs: | ||
| ignore_remote_changes: | ||
| # edit_mode is set by CLI, not user-configurable |
There was a problem hiding this comment.
You mean DABs override user setting? Do you know if that is intentional?
| reason: managed | ||
|
|
||
| backend_defaults: | ||
| # Backend returns PERFORMANCE_OPTIMIZED for serverless jobs when not set |
There was a problem hiding this comment.
Is this field ever set for non-serverless jobs?
Changes
resource.ymlclassification in config-remote-sync instead of custom rulesresource.ymlwith new fieldsWhy
This PR eliminates tech debt, config-remote-sync will be in sync with resource updates
Tests
Existing tests (one snapshot updated because underlying bug was fixed)