[Feature]: Remove ENABLE_AZURE_PVC_UPDATES configuration parameter

Is there an existing issue already for this feature request/idea?

I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

What problem is this feature going to solve? Why should it be added?

The ENABLE_AZURE_PVC_UPDATES configuration was introduced as a workaround for a missing feature in the AKS platform that was preventing CloudnativePG users from resizing volumes.

This feature was implemented at the end of 2022, so it is now time to remove the ENABLE_AZURE_PVC_UPDATES configuration.

Describe the solution you'd like

Remove the ENABLE_AZURE_PVC_UPDATES configuration in version 1.26.0

Describe alternatives you've considered

N/A

Additional context

kubernetes-sigs/azuredisk-csi-driver#273

Backport?

No

Are you willing to actively contribute to this feature?

Yes

Code of Conduct

I agree to follow this project's Code of Conduct

This is linked to #5974

@armru

After discussing with @armru, it's unlikely that anyone is still using this workaround after more than three years, as it is no longer needed. I've updated the description to remove the option in version 1.26.0.

@mnencia

@mnencia: I'm using it because I thought I had to, but, I can try turning it off. This was the primary reason I didn't use the helm chart, at the time, I don't think it exposed the way to pass this.

@jmealo

@jmealo, based some preliminary tests, the feature should function correctly when the flag is set to "off" in any currently available version of the Azure CSI driver. However, it appears to remain stuck when the flag is enabled. It would be very helpful if you could confirm this.

@mnencia

@mnencia Could you help explain what you mean by it being "stuck" when it's on? 🤔 I can try turning it off for sure. What would I need to do to test?

@jmealo

@jmealo After a resize, the Cluster gets stuck in Waiting for the instances to become active phase.

I've never seen that with it turned on. Will try to test this week.

@mnencia

@mnencia: As it turns out, I can’t reliably test whether turning this off breaks anything — because it seems I didn’t actually apply the config correctly in the first place to enable the flag.

That said, I can 100% confirm that PVC resizing works fine on Azure. All of our AKS clusters have the CSI driver available, and volume resizing is functioning as expected.

For context, I don’t use Helm — just the operator directly. Here’s how I thought I was enabling this flag:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: staging-pg-common
  namespace: db
spec:
  instances: 3
  logLevel: trace

  env:
    - name: ENABLE_AZURE_PVC_UPDATES
      value: "true"

When I check the Environment ConfgiMap:

kubectl describe configmap -n cnpg-system cnpg-controller-manager-env-g77c8fhf2g
Name:         cnpg-controller-manager-env-g77c8fhf2g
Namespace:    cnpg-system
Labels:       <none>
Annotations:  <none>

Data
====
POSTGRES_IMAGE_NAME:
----
ghcr.io/cloudnative-pg/postgresql:17.4


BinaryData
====

Events:  <none>

When I describe the controller manager pod:

➜  k8s git:(main) ✗ kubectl describe pod -n cnpg-system cnpg-controller-manager-66f75f4ff4-cr724 
Name:             cnpg-controller-manager-66f75f4ff4-cr724
Namespace:        cnpg-system
Priority:         0
Service Account:  cnpg-manager
Node:             aks-main-32437045-vmss00000j/10.130.82.229
Start Time:       Tue, 25 Feb 2025 15:57:12 -0500
Labels:           app.kubernetes.io/name=cloudnative-pg
                  pod-template-hash=66f75f4ff4
Annotations:      <none>
Status:           Running
SeccompProfile:   RuntimeDefault
IP:               10.130.83.19
IPs:
  IP:           10.130.83.19
Controlled By:  ReplicaSet/cnpg-controller-manager-66f75f4ff4
Containers:
  manager:
    Container ID:    containerd://72accdd1f87469b6b903505a6868e14f6eeef8330b066ff838a8e3fdd6ff7146
    Image:           docker.gisual.net/cloudnative-pg-testing:debug-deploy-1
    Image ID:        docker.gisual.net/cloudnative-pg-testing@sha256:f9aeb85105ff5d912a5d2c7da1bddedb3e24b006adde4c79fedbcc07a645ba6b
    Ports:           6060/TCP, 8080/TCP, 9443/TCP
    Host Ports:      0/TCP, 0/TCP, 0/TCP
    SeccompProfile:  RuntimeDefault
    Command:
      /manager
    Args:
      controller
      --leader-elect
      --config-map-name=cnpg-controller-manager-config
      --secret-name=cnpg-controller-manager-config
      --webhook-port=9443
      --log-level=debug
      --pprof-server=true
    State:          Running
      Started:      Tue, 18 Mar 2025 20:33:03 -0400
    Last State:     Terminated
      Reason:       Error
      Exit Code:    2
      Started:      Tue, 18 Mar 2025 20:27:22 -0400
      Finished:     Tue, 18 Mar 2025 20:27:52 -0400
    Ready:          True
    Restart Count:  21
    Limits:
      cpu:     500m
      memory:  1Gi
    Requests:
      cpu:      100m
      memory:   256Mi
    Liveness:   http-get https://:9443/readyz delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get https://:9443/readyz delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment Variables from:
      cnpg-controller-manager-env-g77c8fhf2g  ConfigMap  Optional: false
    Environment:
      PULL_SECRET_NAME:              cnpg-pull-secret
      OPERATOR_IMAGE_NAME:           docker.gisual.net/cloudnative-pg-testing:debug-deploy-1
      OPERATOR_NAMESPACE:            cnpg-system (v1:metadata.namespace)
      MONITORING_QUERIES_CONFIGMAP:  cnpg-default-monitoring
    Mounts:
      /controller from scratch-data (rw)
      /run/secrets/cnpg.io/webhook from webhook-certificates (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-4bjtz (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True 
  Initialized                 True 
  Ready                       True 
  ContainersReady             True 
  PodScheduled                True 
Volumes:
  scratch-data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  webhook-certificates:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  cnpg-webhook-cert
    Optional:    true
  kube-api-access-4bjtz:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

👍 I vote to remove this.

When triggering two operations (VM +disk update) at the same time, the operator asks the pod restart for VM upgrade to complete. Azure preserves both PVC conditions at the same time, while AWS & GCP removes the Resizing one when it adds the FileSystemResizePending. This will force the operator to wait and not recreate the pod on the new VM.

diff --git a/pkg/reconciler/persistentvolumeclaim/resources.go b/pkg/reconciler/persistentvolumeclaim/resources.go
index 1ca30256f..bcaaef34a 100644
--- a/pkg/reconciler/persistentvolumeclaim/resources.go
+++ b/pkg/reconciler/persistentvolumeclaim/resources.go
@@ -65,15 +65,21 @@ external:
        return true
 }

-// isResizing returns true if PersistentVolumeClaimResizing condition is present
+// isResizing returns true if PersistentVolumeClaimResizing condition is present and not PersistentVolumeClaimFileSystemResizePending
 func isResizing(pvc corev1.PersistentVolumeClaim) bool {
+       isResizing := false
+       isFileSystemResizePending := false
+
        for _, condition := range pvc.Status.Conditions {
                if condition.Type == corev1.PersistentVolumeClaimResizing {
-                       return true
+                       isResizing = true
+               }
+               if condition.Type == corev1.PersistentVolumeClaimFileSystemResizePending {
+                       isFileSystemResizePending = true
                }
        }

-       return false
+       return (isResizing && !isFileSystemResizePending)
 }

This is the commit in the azuredisk-csi-driver that fixes the issue kubernetes-sigs/azuredisk-csi-driver@8bee39b

It was released in version 1.11.0

feat: remove Azure CSI driver resize workaround (#7297)

Navigation Menu

Repository navigation

[Feature]: Remove ENABLE_AZURE_PVC_UPDATES configuration parameter #7296

Is there an existing issue already for this feature request/idea?

What problem is this feature going to solve? Why should it be added?

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Backport?

Are you willing to actively contribute to this feature?

Code of Conduct

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature]: Remove ENABLE_AZURE_PVC_UPDATES configuration parameter #7296

Description

Is there an existing issue already for this feature request/idea?

What problem is this feature going to solve? Why should it be added?

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Backport?

Are you willing to actively contribute to this feature?

Code of Conduct

Activity

mnencia commented on Apr 7, 2025

mnencia commented on Apr 7, 2025

jmealo commented on Apr 7, 2025

mnencia commented on Apr 7, 2025

jmealo commented on Apr 7, 2025

mnencia commented on Apr 7, 2025

jmealo commented on Apr 7, 2025

jmealo commented on Apr 8, 2025

jmealo commented on Apr 8, 2025

nfaust-edb commented on Apr 8, 2025

mnencia commented on Apr 9, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions