Repository navigation
Support DMS migration during bundle deploy - #6989
shreyas-goenka wants to merge 42 commits into
Conversation
Integration test reportCommit: f90499d
6 interesting tests: 5 FAIL, 1 flaky
Top 11 slowest tests (at least 2 minutes):
|
| } | ||
| // Deployment history reads remote state even without --force-pull. | ||
| t0 := time.Now() | ||
| phases.Initialize(ctx, b) |
There was a problem hiding this comment.
why do we call Initialize() in PostInitFunc?
There was a problem hiding this comment.
To make debug states work for DMS. Without this, if you don't specify --force-pull this command would not pull in remote state.
This bit was added to make some tests work that rely on the debug state pulling remote state work with DMS as well.
There was a problem hiding this comment.
For DMS the point of --force-pull is moot, right? Can we update here:
SkipInitialize: !forcePull && !IsDMS,
?
This seems a bit narrow? In direct we have env var and config setting. Config setting is consulted first, then env var, then state-derived, then the default. Important also that state is sticky, so if you are on DMS and neither config nor env var are set, you still remain on DMS and not migrated back. Do we have that? The config setting/env var/stickiness is complex enough so that it warrants its own PR, what do you think? |
| func PullResourcesState(ctx context.Context, b *bundle.Bundle, alwaysPull AlwaysPull) *StateDesc { | ||
| var err error | ||
|
|
||
| // We read all 4 possible states: terraform/direct X local/remote and pick the most recent one. |
There was a problem hiding this comment.
Why was this comment removed, is it not relevant anymore?
There was a problem hiding this comment.
It's a bit outdated. We prioritize DMS even when local states have a higher serial (because for DMS, resources.json does not have a serial)
This actually highlights a gap. If a user has DMS, removes the config, has a outdated local resources.json and then does a deployment, they'll end up overriding the DMS feature.
I think we need to keep serial around in resources.json to mitigate this. Otherwise this problem does not go away.
…s-deploy-migration
…s-deploy-migration
…s-deploy-migration
…s-deploy-migration
Stack
This PR is based on #7046. Configuration precedence and serial persistence are reviewed in the preceding PRs; the remaining diff is migration and the remote-state selection required to decide when migration runs.
Human description:
This PR:
experimental.deployment_history: falseis set, same asbundle.direct.AI summary
Changes
Before migration, copy remote
resources.jsontoresources.json.backup. Register its resources usingINITIAL_REGISTERin versionmax(direct serial, last DMS version) + 1, complete that version, then run the deployment in the following version when operations exist. Preserve resource IDs, state, and dependencies, and log the migration and deployment URLs separately.A remote state file without the history marker triggers migration even when DMS already has versions. State selection therefore uses the remote marker rather than a stale local cache. The serial is persisted by #7046 but remains a cache of the service-owned version.
Saved direct-state plans cannot yet be applied during migration; the TODO records this as a blocker for automatic migration after GA. No special DMS initialization is added to
bundle debug states; the new cache test uses--force-pull.Tests
Implemented with Codex, using Astra for planning and Sol subagents for implementation and testing.