bundle/direct: add a feature-flag list to the direct deployment state#5403
bundle/direct: add a feature-flag list to the direct deployment state#5403shreyas-goenka wants to merge 1 commit into
Conversation
Integration test reportCommit: 17b0ef2
22 interesting tests: 13 SKIP, 7 KNOWN, 2 flaky
Top 24 slowest tests (at least 2 minutes):
|
ad20bc3 to
ccbd8f1
Compare
ccbd8f1 to
cefabe0
Compare
cefabe0 to
e70bc2c
Compare
e70bc2c to
e1babf2
Compare
e1babf2 to
d15b537
Compare
d15b537 to
fab41cc
Compare
fab41cc to
ea32c1d
Compare
ea32c1d to
cf5f00d
Compare
cf5f00d to
69c7de4
Compare
69c7de4 to
522d49e
Compare
522d49e to
47fbd29
Compare
|
|
||
| // Enforce the recorded DMS protocol version only when this bundle has | ||
| // opted into DMS; a bundle that has not opted in does not act on it. | ||
| if b.Config.Experimental != nil && b.Config.Experimental.RecordDeploymentHistory { |
There was a problem hiding this comment.
if the config is not set - the deployment just falls back to direct deplioyment.
Approval status: pending
|
| func TestStateSchemaVersions(t *testing.T) { | ||
| assert.Equal(t, 2, currentStateVersion) | ||
| assert.Equal(t, 3, dmsStateVersion) | ||
| assert.Equal(t, 1, currentDmsVersion) |
There was a problem hiding this comment.
What does this test? We know constants in golang work.
There was a problem hiding this comment.
This is a tripwire test that will trigger anytime someone does a version bump. This forces the author and reviewer to read the instructions above and not miss them.
|
|
||
| title "without the flag, the same state is accepted (the check is gated on opt-in)" | ||
| trace update_file.py databricks.yml "record_deployment_history: true" "record_deployment_history: false" | ||
| trace errcode $CLI bundle plan 2>&1 | contains.py "!is newer than supported version" |
There was a problem hiding this comment.
What happens if experimental flag is removed? Do we stop calling DMS but keep using normal direct engine? Do we keep version 3 or 2 in that case?
There was a problem hiding this comment.
Do we stop calling DMS but keep using normal direct engine?
Yes, we fall back to normal direct engine. It works fine because we'll continue to maintain direct state with WAL and resources.json as we preview.
There was a problem hiding this comment.
Do we keep version 3 or 2 in that case?
We keep version 3. The configuration remains the source of truth for whether to use direct or DMS (provide easy fallback for customers).
47fbd29 to
94d066e
Compare
94d066e to
cf6ef38
Compare
cf6ef38 to
230c84d
Compare
Bumps the direct state schema to version 3, which adds a per-state feature list (Header.Features) mapping each recorded feature flag to the CLI version that wrote it. From v3 on, additive capabilities are recorded as feature flags rather than schema-version bumps: a CLI that loads a state recording a feature it does not understand errors and points the user at the minimum CLI version recorded in the state. record_deployment_history is the first such feature. Older CLIs (max state version 2) reject v3 state with the existing "upgrade the CLI" error; record_deployment_history is still rejected under the terraform engine, which does not support it. Co-authored-by: Isaac
230c84d to
17b0ef2
Compare
|
Superseded by #5660, which is a clean, minimal version focused solely on the feature-flag mechanism (no DMS/record_deployment_history cruft). |
Why
The direct deployment state needs a forward-compatibility mechanism: as the engine gains capabilities (the first is
experimental.record_deployment_history/ DMS), a state written by a newer CLI may rely on something an older CLI doesn't understand. Rather than bump the schema version for every such capability, we add a generic feature-flag list to the state. An older CLI that finds a feature it doesn't recognize fails with an actionable message instead of silently mishandling the state.What
Header.Features— a map of feature name → the CLI version that recorded it. (Older CLIs, max v2, reject v3 with the existing "upgrade the CLI" error; this is the one schema bump, after which capabilities are feature flags, not version bumps.)Openrejects any state that records a feature this CLI doesn't know, naming the feature and the minimum CLI version recorded in the state:the deployment state requires feature "X" which this CLI (<v>) does not support; upgrade to <minVersion> or newer.RecordFeature), stamping the current CLI version as the minimum.record_deployment_historyis the first feature.record_deployment_historyis still rejected under the terraform engine (it drives DMS, which only the direct engine supports).Tests
dstate): schema-version pin + migrations-completeness tripwire, legacy→current migration, reject-newer-version,RecordFeatureround-trip + panic-if-WAL-started, andcheckSupportedFeatures(known accepted / unknown rejected).bundle/state/unknown_feature— a state requiring an unknown feature is rejected with the recorded min version.record-deployment-history/state-upgrade— deploy without the flag (no features) → with the flag (feature recorded) → older CLI (v1.0.0) rejects v3.record-deployment-history/terraform-unsupported— the flag is rejected under terraform.state_version: 3.This pull request and its description were written by Isaac.