feat(api): immutability rules for DatabaseDeclaration and DbPolicy identity fields#469
Merged
Merged
Conversation
…table Add XValidation `self == oldSelf` to: - DatabaseDeclaration: spec.classifier, spec.type - DbPolicy: spec.microserviceName Closes a consistency gap with ExternalDatabase (which already locks classifier/type/dbName) and NamespaceBinding (which locks operatorNamespace). All four workload CRs now treat identity as frozen at create-time; retargeting requires delete + recreate. Regenerated CRDs (config/, config-dev/, helm-templates/) via `make manifests`. Updated docs/howto/DBaaS Operator.md to mark the fields as immutable with rationale. go build + go test green. Java IT suite scanned for `.edit()` mutations of the now-immutable fields — none exist for DD/DbPolicy, so existing tests remain valid.
Five integration tests in OperatorIT.java mirroring the existing ExternalDatabase immutability suite: - testDatabaseDeclarationTryToUpdateClassifier - testDatabaseDeclarationTryToUpdateType - testDatabaseDeclarationCanUpdateSettings (negative confirmation) - testDbPolicyTryToUpdateMicroserviceName - testDbPolicyCanUpdateServices (negative confirmation) Each immutability test creates a CR, attempts to mutate the protected field via .edit(), and asserts HTTP 422 + the matching XValidation message. The two "Can*" tests confirm that mutable fields (DD.settings, DbPolicy.services) still accept updates and the CR converges back to Succeeded — guarding against the immutability rule accidentally clamping more than the intended fields. mvn clean test-compile green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DatabaseDeclaration.spec.classifierDatabaseDeclaration.spec.typeDbPolicy.spec.microserviceNameExternalDatabase(already locksclassifier,type,dbName) andNamespaceBinding(already locksoperatorNamespace). All four workload CRs now treat identity fields as frozen after create; retargeting requires delete + recreate.config/,config-dev/, andhelm-templates/.docs/howto/DBaaS Operator.mdmarks the fields as immutable with rationale, plus a one-line note in the high-level "Key design decisions" section.Why these fields are dangerous to mutate
DD.classifier— switching the classifier on an existing CR re-targets the controller at a different database whilestatus.trackingID/status.observedGenerationstill reference the original one. In-flight async operation becomes irrecoverable.DD.type— changing engine type mid-flight requests provisioning of a fresh database on a different adapter while the original stays registered under the same CR identity.DbPolicy.microserviceName— rewriting role grants under the same K8s object destroys the audit link to who created the policy originally.Integration test coverage
Five tests added to
OperatorIT.javamirroring the existing EDB immutability suite:testDatabaseDeclarationTryToUpdateClassifiertestDatabaseDeclarationTryToUpdateTypetestDatabaseDeclarationCanUpdateSettingsspec.settingsstill mutable, CR converges back toSucceededtestDbPolicyTryToUpdateMicroserviceNametestDbPolicyCanUpdateServicesspec.servicesstill mutable, CR converges back toSucceeded, new service visible viagetAccessRolesTest plan
go build ./...— Successgo test ./...— green acrossapi/v1,internal/client,internal/controller,internal/ownershipmvn clean test-compileondbaas-integration-tests— green.edit()call sites inOperatorIT.java: none mutate the now-immutable DD/DbPolicy fields, so no existing test fails