Problem Statement
Starting with Db2 12.1.5, the Db2uInstance admission webhook enforces a restriction whereby dbConfig, dbmConfig, and registry (db2set) settings can only be specified during initial Db2uInstance creation.
Subsequent updates to these sections of the Custom Resource are rejected and administrators are required to perform configuration changes through native Db2 commands instead.
After deployment, changes to database configuration parameters (db cfg) and database manager configuration parameters (dbm cfg) are not supported through updates to the Db2uInstance custom resource. Any updates must be performed using native Db2 commands.
While this approach may simplify operator behaviour, it significantly reduces the ability to manage Db2 deployments using standard Kubernetes and GitOps practices.
The Db2uInstance Custom Resource is expected to represent the desired state of the Db2 deployment. Preventing configuration changes through the CR breaks this declarative model and forces administrators back to imperative operational procedures.
Business and Operational Impact
1. Configuration Drift Becomes Unavoidable
Once configuration changes are performed using native Db2 commands such as:
- db2 update db cfg
- db2 update dbm cfg
- db2set
the runtime state immediately diverges from the configuration stored in Git and represented by the Db2uInstance CR.
As a result:
- Git is no longer the authoritative source of truth.
- Operators must maintain additional documentation outside Kubernetes.
- Auditing and change tracking become significantly more complex.
2. GitOps and ArgoCD Workflows Are Broken
GitOps platforms such as ArgoCD and Flux rely on the principle that all desired configuration is stored declaratively in Git and reconciled continuously by the platform.
With the current restriction:
- Configuration changes cannot be delivered through pull requests.
- Standard promotion workflows (DEV → TEST → PROD) no longer work.
- ArgoCD cannot reconcile Db2 configuration settings.
- Configuration management requires manual or custom automation outside the Kubernetes control plane.
This creates an inconsistency between Db2 and the operational model used by most cloud-native platforms.
3. Disaster Recovery and Cluster Rebuild Risks
In a cluster rebuild or disaster recovery scenario, only the values contained in the Db2uInstance CR are automatically restored.
Configuration changes applied after deployment using native Db2 commands are not represented in the Custom Resource and therefore risk being lost unless separately documented and re-applied.
This introduces additional operational risk and increases recovery complexity.
4. Reduced Automation Capabilities
Many organizations manage platform configuration exclusively through declarative infrastructure-as-code pipelines.
The current design requires:
- imperative administration steps,
- custom post-deployment scripts,
- additional Ansible jobs,
- or bespoke automation frameworks
to achieve functionality that was previously handled through standard CR reconciliation.
This increases operational complexity and support effort for both customers and IBM.
Requested Enhancement
Re-enable support for updating the following configuration sections through the Db2uInstance Custom Resource after deployment:
- dbConfig
- dbmConfig
- Registry / db2set settings
The Db2 operator should reconcile these values in the same way as during initial deployment.
Where specific parameters require instance or database restart actions, the operator could:
- automatically perform supported restart operations,
- expose restart requirements through CR status conditions,
- or provide clear validation and reconciliation feedback.
Further if possible: When using the Db2 native commands to change configuration, it would be best if the changed config could also find its way around back in the CR on a suitable way.
Expected Benefits
Alignment with Kubernetes Principles
The Db2uInstance CR once again becomes the authoritative declaration of desired database state.
Full GitOps Compatibility
Organizations using ArgoCD, Flux, OpenShift GitOps, or similar tools can manage Db2 configuration through standard Git-based deployment processes.
Improved Disaster Recovery
All supported configuration remains captured within Kubernetes resources and can be reconstructed during cluster recovery.
Reduced Operational Complexity
Administrators can manage Db2 configuration consistently through Kubernetes APIs rather than maintaining separate operational procedures for Day-2 configuration changes.
Summary
The current restriction introduced in Db2 12.1.5 prevents Db2 configuration from being managed declaratively after deployment and introduces unnecessary friction for customers adopting Kubernetes-native operational models.
Re-enabling post-deployment reconciliation of dbConfig, dbmConfig, and registry (db2set) settings would restore alignment with GitOps principles, reduce configuration drift, improve recoverability, and provide a significantly better cloud-native operational experience for Db2 on OpenShift.
The idea, that Gitops cannot control the runtime behaviour is not meaningful and it looks like we are not sticking to cloud native best practise. We made similar experiences in other IBM product where people thought it is a good idea to shorten the learn curve for existing administrators. But reality is different. If a customer makes the step towards DB2 containerized, then he want to leverage all benefits from a cloud native setup. At the moment the mixture of legacy DB2 commandi and the golden record (CRD file from GIT) is not ideal. I strongly recommend and ask for a way that changes on the GIT will be transported and applied strictly at runtime.