test: add e2e schema-upgrade test for two-phase extension migration#426
test: add e2e schema-upgrade test for two-phase extension migration#426WentingWu666666 wants to merge 1 commit into
Conversation
fc8c030 to
aad154d
Compare
|
🤖 Auto-triaged by documentdb-triage-tool. Applied: Reasoningcomponent from path globs (test, ci, docs); effort from diff stats (275+0 LOC, 5 files); LLM: Adds a new e2e test file covering the two-phase extension schema upgrade path, directly addressing a release-blocking gap (0.3.0 version bump deferred due to missing coverage), scoped to the test component within one upgrade suite. If a label is wrong, remove it manually and ping |
Add a High-level, disruptive upgrade spec that gates the safety of
bumping the default DocumentDB version. It exercises the irreversible
extension schema migration (ALTER EXTENSION documentdb UPDATE) that the
image-only upgrade spec deliberately does not cover.
The spec drives the upgrade through the user-facing knobs —
spec.documentDBVersion (which sets the extension + gateway images
together) and spec.schemaVersion — rather than raw spec.image.*
overrides, mirroring how an operator user actually bumps a version:
1. create at the old version with schemaVersion unset and seed data;
status.schemaVersion settles on the old semver
2. bump spec.documentDBVersion to the new version; pods roll but the
schema must stay at the old version (no auto ALTER EXTENSION) and
seeded data is retained
3. finalize by setting spec.schemaVersion; the operator runs
ALTER EXTENSION UPDATE, status.schemaVersion advances and seeded
data is still retained
The old/new versions default to the last-released pair (0.109.0 →
0.110.0) so the spec runs on every e2e PR via the existing `upgrade`
matrix row (E2E_UPGRADE=1, Medium depth); admins may override via
E2E_UPGRADE_OLD/NEW_DOCUMENTDB_VERSION repo vars. A new
manifests/mixins/documentdb_version.yaml.template pins the version at
create time.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b8370a70-9c47-476c-8d6e-b9a75a8ced64
Signed-off-by: Wenting Wu <wentingwu@microsoft.com>
aad154d to
35c5051
Compare
There was a problem hiding this comment.
Pull request overview
Adds an end-to-end upgrade spec that exercises the two-phase DocumentDB extension schema migration path (the irreversible ALTER EXTENSION ... UPDATE) using the user-facing spec.documentDBVersion + spec.schemaVersion knobs, closing a gap left by the existing image-only upgrade coverage.
Changes:
- Add a new upgrade e2e spec (
upgrade_schema_test.go) that verifies: binary upgrade does not auto-migrate schema in two-phase mode, then explicit finalization migrates schema while retaining seeded data. - Add a manifests mixin to pin
spec.documentDBVersionat creation time, plus new env vars/defaults to control the old/new version pair. - Wire the new env vars into CI and document them in the e2e README.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
test/e2e/tests/upgrade/upgrade_schema_test.go |
New e2e spec covering two-phase schema migration and data retention across binary + schema upgrade steps. |
test/e2e/tests/upgrade/helpers_test.go |
Adds env var knobs and defaults for old/new DocumentDB versions used by the schema-upgrade spec. |
test/e2e/README.md |
Documents the new schema-upgrade env vars and their defaults. |
test/e2e/manifests/mixins/documentdb_version.yaml.template |
New mixin to set spec.documentDBVersion via rendered manifests at create time. |
.github/workflows/test-e2e.yml |
Sets version env vars so the schema-upgrade spec runs consistently in CI. |
| func schemaVersionGetter(ctx context.Context, c client.Client, key types.NamespacedName) func() string { | ||
| return func() string { | ||
| dd, err := shareddb.Get(ctx, c, key) | ||
| if err != nil { | ||
| return "" | ||
| } | ||
| return dd.Status.SchemaVersion | ||
| } | ||
| } |
| key := types.NamespacedName{Namespace: ns, Name: ddName} | ||
| Eventually(assertions.AssertDocumentDBReady(ctx, c, key), | ||
| timeouts.For(timeouts.DocumentDBReady), | ||
| timeouts.PollInterval(timeouts.DocumentDBReady), | ||
| ).Should(Succeed(), "DocumentDB did not reach Ready on oldVersion=%s", oldVersion) | ||
|
|
||
| By("waiting for status.schemaVersion to settle on the old version") | ||
| Eventually(schemaVersionGetter(ctx, c, key), | ||
| timeouts.For(timeouts.DocumentDBReady), | ||
| timeouts.PollInterval(timeouts.DocumentDBReady), | ||
| ).Should(Equal(oldVersion), "initial schema version should be %s", oldVersion) | ||
|
|
| Consistently(schemaVersionGetter(ctx, c, key), | ||
| 30*time.Second, 5*time.Second, | ||
| ).Should(Equal(oldVersion), | ||
| "schema must remain at %s until spec.schemaVersion is set (two-phase)", oldVersion) |
| By("waiting for ALTER EXTENSION UPDATE to advance status.schemaVersion to the new version") | ||
| Eventually(schemaVersionGetter(ctx, c, key), | ||
| timeouts.For(timeouts.DocumentDBUpgrade), | ||
| timeouts.PollInterval(timeouts.DocumentDBUpgrade), | ||
| ).Should(Equal(newVersion), "schema did not migrate to %s after finalize", newVersion) | ||
|
|
What
Adds a new e2e upgrade spec —
test/e2e/tests/upgrade/upgrade_schema_test.go— that covers the two-phase extension schema upgrade (the irreversibleALTER EXTENSION documentdb UPDATEmigration) that the existing image-only upgrade spec (upgrade_images_test.go) deliberately does not exercise.Why
Today we cannot gate a bump of the default DocumentDB version on schema-migration safety — there is no e2e coverage of the extension schema upgrade path. This showed up while preparing the operator 0.3.0 release: the database version bump was deferred because we had no way to prove the schema migration is safe. This test closes that gap.
Approach
Drives the upgrade through the user-facing knobs —
spec.documentDBVersion(which sets the extension + gateway images together) andspec.schemaVersion— rather than rawspec.image.*overrides, mirroring how a real user bumps a version. A new mixinmanifests/mixins/documentdb_version.yaml.templatepins the version at create time.Flow (per the two-phase contract documented on
spec.schemaVersion):schemaVersionunset (two-phase) and seed data →status.schemaVersionsettles on the old semver.spec.documentDBVersionto the new version → pods roll (status.documentDBImageadvances), but schema must stay at the old version (no autoALTER EXTENSION), seeded data retained. Held withConsistentlyso a stray auto-migration fails.spec.schemaVersionto the new version → operator runsALTER EXTENSION UPDATE,status.schemaVersionadvances, seeded data still retained.Runs on every e2e PR
upgradematrix row, which already setsE2E_UPGRADE=1on PRs.SkipUnlessLevel(High)), which runs at the PR default depth (Medium).0.109.0 → 0.110.0(public GHCR images) so the spec runs without depending on repo CI vars. Overridable viaE2E_UPGRADE_OLD_DOCUMENTDB_VERSION/E2E_UPGRADE_NEW_DOCUMENTDB_VERSION.Status
Draft — not yet run end-to-end against a live cluster (compiles/vets clean). Opening for early review of the approach and assertions.
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com