-
Notifications
You must be signed in to change notification settings - Fork 18
Description
Summary
Enable users to specify which DocumentDB extension version to deploy via spec.documentDBVersion, add version validation and upgrade path enforcement, and expand the upgrade CI workflow to test version transitions using spec.documentDBVersion.
Details
Background:
The spec.documentDBVersion field and DOCUMENTDB_VERSION environment variable are implemented but not actively validated or enforced. This issue combines version management activation with comprehensive upgrade testing.
Blocked By: Gateway images with version tags are currently broken: The documentdb-local:pg16-0.1XX.0 images in the documentdb repository were built for standalone mode (where PostgreSQL runs inside the same container with Unix socket), not for CNPG sidecar mode (where PostgreSQL runs in a separate container with TCP only). These images cannot be used with the Kubernetes operator's CNPG-based architecture.
Impact: We only have one working documentdb-local image (:16 tag), so we cannot:
- Set
documentDBVersionfor gateway deployments - Test gateway image upgrades between versions
Once versioned gateway images are rebuilt for CNPG sidecar mode, we can enable full version management.
Current State:
spec.documentDBVersionfield exists in DocumentDB CRDstatus.documentDBVersiontracks the current running versionDOCUMENTDB_VERSIONenv var is set on gateway container- Version extraction from image tag implemented in
util.go - Basic upgrade workflow tests extension images only (0.109.0 → 0.110.0)
- Gateway image upgrade testing is blocked (only one working image)
What's Missing:
Version Management:
- Version format validation (ensure valid semver like
0.110.0) - Version compatibility matrix documentation
- Upgrade path validation (prevent downgrades without explicit flag)
- Gateway version support (blocked on image fixes)
CI Testing:
- Use
spec.documentDBVersionin upgrade workflow tests - Version matrix for multiple upgrade paths
- Gateway image upgrade testing (blocked on image fixes)
- Downgrade prevention testing
Implementation Steps:
-
Add version validation in controller:
func validateDocumentDBVersion(version string) error { // Validate version format matches X.Y.Z pattern // Return error for invalid formats }
-
Add upgrade path validation:
func canUpgrade(currentVersion, targetVersion string) bool { // Parse semver versions // Ensure targetVersion >= currentVersion // Allow downgrade only with explicit annotation }
-
Add condition to DocumentDB status for version validation errors
-
Update public documentation with supported versions
-
Update upgrade CI workflow to use
spec.documentDBVersion:jobs: test-upgrade: strategy: matrix: upgrade: - from_version: "0.109.0" to_version: "0.110.0" - from_version: "0.110.0" to_version: "0.111.0" architecture: [amd64, arm64] steps: - name: Deploy with spec.documentDBVersion = ${{ matrix.upgrade.from_version }} - name: Update spec.documentDBVersion to ${{ matrix.upgrade.to_version }} - name: Verify data persistence - name: Rollback spec.documentDBVersion to ${{ matrix.upgrade.from_version }}
Example Usage:
apiVersion: documentdb.io/preview
kind: DocumentDB
metadata:
name: my-cluster
spec:
documentDBVersion: "0.110.0" # Pin to specific versionTest Scenarios:
Currently Possible (extension images work):
- Extension upgrade via
spec.documentDBVersionchange - Extension rollback via
spec.documentDBVersionchange - Downgrade prevention testing
Blocked (waiting for versioned gateway images):
4. Gateway-only upgrade (extension stays same version)
5. Both extension + gateway upgrade simultaneously
6. Skip-version upgrade (e.g., 0.109.0 → 0.111.0)
Acceptance Criteria:
Phase 1 (extension only):
- Users can specify
spec.documentDBVersion: "0.110.0" - Controller validates version format and rejects invalid versions
-
status.documentDBVersionaccurately reflects running version - Upgrade workflow tests use
spec.documentDBVersionin DocumentDB spec - Extension upgrade from 0.109.0 → 0.110.0 works via spec change
- Downgrade is blocked (or requires explicit annotation)
Phase 2 (after gateway images fixed):
- Gateway version management enabled
- Gateway upgrade tested separately from extension
- Workflow uses full version matrix for both extension and gateway