* Skip owner references on user secrets when secret deletion is disabled
Kubernetes garbage-collects owner-referenced secrets as soon as the
owning Postgresql resource is deleted, regardless of the operator's
own EnableSecretsDeletion check in Delete() (which only guards the
operator's explicit deleteSecrets() call, not GC). This made
enable_secrets_deletion=false ineffective whenever
enable_owner_references was also enabled, since GC removed the
credential secrets anyway.
Now the generated secrets are not removed when
enable_owner_references: true, enable_secrets_deletion: false.
* Document skip-owner-refs on user secrets when deletion disabled
- refresh inline comment in generateSingleUserSecret
- extend enable_owner_references / enable_secrets_deletion docs in
operator_parameters.md to describe the interaction
- clarify in operator_parameters.md that the protection takes effect
on the cluster's next sync after the setting is applied
- add third exception in administrator.md "Owner References and Finalizers"
- add TestGenerateSingleUserSecret_OwnerReferences covering all four
flag combinations plus the cross-namespace cases
---------
Co-authored-by: Serdar Dalgıç <sd@serdardalgic.org>
configuration.sidecars was annotated with kubebuilder:validation:Type=object
while SidecarContainers is a []v1.Container, so the generated schema rejected
every list value and global sidecars could not be configured at all.
Drop the hand-written Schemaless/Type=object markers and let controller-gen
derive the schema from the Go type, the same way spec.initContainers is
already handled in the Postgresql CRD. The field now renders as type: array
with a full Container schema for its items.
Fixes#3159
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The postgresql_versions array had a trailing comma after "14" in two places
that build OPERATOR_UI_CONFIG as JSON. OPERATOR_UI_CONFIG is parsed by the UI
with Python's json.loads() (operator_ui/main.py), which rejects trailing
commas, so the config fails to load:
json.decoder.JSONDecodeError: Expecting value: line 25 column 3
Remove the trailing comma in:
- charts/postgres-operator-ui/templates/deployment.yaml (chart Deployment)
- ui/run_local.sh (local dev default_operator_ui_config)
ui/manifests/deployment.yaml and the Python DEFAULT_UI_CONFIG in
operator_ui/main.py were already correct.
Fixes#3062
Upgrading to v2.0.0 fails at the CRD apply step. The apiserver rejects the
OperatorConfiguration CRD:
CustomResourceDefinition "operatorconfigurations.acid.zalan.do" is invalid:
...oauth_token_secret_name.default: Invalid value: "string": in body must
be of type object
Root cause: these CRDs are generated by controller-gen from the Go types.
spec.NamespacedName is a struct {Namespace, Name}, so controller-gen emits an
object schema for every NamespacedName field. But NamespacedName has custom
MarshalJSON/UnmarshalJSON that (de)serialize it as a plain JSON string
("namespace/name"). The generated object schema therefore never matched how
the operator actually reads and writes these fields (it did in 1.15.x, where
they were type: string).
For oauth_token_secret_name this is a hard failure: it also carries
`// +kubebuilder:default=postgres-operator`, and a scalar string default on an
object-typed property is rejected by the apiserver, blocking the whole
1.15.x -> 2.0.0 upgrade before the operator Deployment is touched.
Fix at the source by annotating the NamespacedName type with
`// +kubebuilder:validation:Type=string` and regenerating the CRDs. This makes
controller-gen emit `type: string` for all NamespacedName fields
(oauth_token_secret_name, infrastructure_roles_secret_name,
pod_environment_configmap, and the nested infrastructure role secretname),
matching their runtime serialization and restoring 1.15.x behaviour. A
field-level Type override cannot be used here: it conflicts with the
struct-derived schema ("object vs string in allOf") and fails generation.
Regenerated manifests/operatorconfiguration.crd.yaml and its two synced
copies (pkg/apis/... embed source and charts/.../crds). Verified with a
server-side dry-run apply: the unpatched CRD is rejected, the regenerated CRD
is accepted.
Fixes#3143
* Use maxUnavailable for the critical-op PDB to stop idle alert noise
The critical-op PDB is created with minAvailable equal to
numberOfInstances while its selector (critical-operation=true) matches
no pods during normal operation. This leaves status.desiredHealthy at N
and currentHealthy at 0 permanently, so monitoring stacks fire alerts
like kube-prometheus-stack's KubePdbNotEnoughHealthyPods for every idle
cluster (#3020).
maxUnavailable: 0 provides the same protection while a critical
operation is running - no voluntary evictions of labeled pods - but
keeps the budget satisfied (desiredHealthy 0) when nothing matches.
When PDBs are disabled or there are no instances, the budget relaxes to
maxUnavailable 100% instead of minAvailable 0.
Fixes#3020
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Update PDB docs for critical-op maxUnavailable semantics
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Clarify why the two PDBs use different budget fields
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Felix Kunde <felix-kunde@gmx.de>
Add priorityClassName to the connectionPooler cluster spec and a
connection_pooler_priority_class_name operator config default.
Cluster spec overrides the operator default; unset means no priority
class. Applies to both master and replica pooler deployments and is
reconciled on config drift.
* Use minAvalable=SynchronousNodeCount + 1 in primary PDB when master selector is disabled
---------
Co-authored-by: Felix Kunde <felix-kunde@gmx.de>
Co-authored-by: Ida Novindasari <idanovinda@gmail.com>
* fix data to POSIX and sed working on macos
* add ServiceAccountGetter to the newFakeK8sAnnotationsClient for unit tests
* try to update the service account
* use irsa_role_arn since we need the full arn, and remove enable_irsa
* move sa sync code to existing sync.go file to be all together
* change all Irsa to IRSA to follow go idiomatic that capitalize initialisms or acronyms
* using Update instead of Patch for the service account syn
* document the new option and add the key in the values/configs
* add the new option to the administrator docs
* trying to increase the timeout for the flaky test after sync
---------
Co-authored-by: Felix Kunde <felix-kunde@gmx.de>
* update golang and dependencies
* fix incorrect log formatting
* clean mod chache and introduce GOARCH in Dockerfile (choose dynamically)
* remove GO111MODULE mentions
* bump github actions from v2 to v3
* bump docker runners to v7
* use extra event store for backwards compatibility with existing codebase
* updated generated opconfig api
* feat(logical-backup): add configurable job history limits and TTL
Adds three new configuration options for logical backup cronjobs:
- logical_backup_successful_jobs_history_limit (default: 3)
- logical_backup_failed_jobs_history_limit (default: 3)
- logical_backup_ttl_seconds_after_finished (default: 86400)
These options control how many completed/failed backup jobs are
retained by Kubernetes and when finished jobs are automatically
deleted. This prevents accumulation of old backup jobs and pods
in namespaces with many PostgreSQL clusters.
Also updates the CronJob comparison logic to detect changes in
these new fields and trigger reconciliation when needed.
Closeszalando/postgres-operator#1092
* add added the 3 new fieldson crd
* updated gen api
---------
Co-authored-by: Jairo Llopis <jairo@moduon.team>
Co-authored-by: Felix Kunde <felix-kunde@gmx.de>
feat: implement service type NodePort
fix: handle LoadBalancer to NodePort service type transition
move NodePort check before LoadBalancer and remove redundant nodePor
add LB-specific DNS annotations again
* Add cluster_labels and annotations to logical backup CronJob and Jobs
When using the logical backup feature, the CronJob and its created Jobs
were missing the cluster_labels and annotations that are applied to
other cluster resources. This made it difficult to filter or identify
backup jobs using the same labels as other cluster components.
Changes:
- Added ObjectMeta with labels and annotations to JobTemplateSpec
- Updated CronJob ObjectMeta to use the merged labels (including
'application: spilo-logical-backup')
- Updated tests to expect the new labels
Trent Schmidt
adshin21
rasoanaivo-r
Jan Mussler
Felix Kunde
IO ANALYTICA
Juhani Pelli
annielzy
Tiago Condeixa
dependabot[bot]
Pierre Ozoux
Jociele Padilha
Raphael Torquato
Lucas Nikola Pape
Allen Conlon