[BUG] Camellia cluster stuck in Creating when referencing an external Redis account Secret without `secretRefRevision`

[JashBook]

Describe the bug

A Camellia Redis Proxy cluster remains in the Creating phase when it references an account Secret generated by an external Redis cluster through systemAccounts[].secretRef.

The referenced Redis Secret contains the apps.kubeblocks.io/secret-revision annotation, but the Camellia cluster does not automatically populate secretRefRevision.

The KubeBlocks controller repeatedly reports:

wait for referenced account secret default/<redis-cluster>-shard-default revision

and:

has no Credential object redis-default found when resolving vars

To Reproduce

1. Create a Redis cluster with sharding and a secondary service:

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: redisc-urxsry
  namespace: default
spec:
  clusterDef: redis
  topology: cluster
  terminationPolicy: WipeOut
  services:
    - componentSelector: shard
      name: secondary
      serviceName: shard-secondary
      roleSelector: secondary
      spec:
        ports:
          - name: redis-cluster
            port: 6379
            protocol: TCP
            targetPort: redis-cluster
  shardings:
    - name: shard
      shards: 3
      shardingDef: redis-cluster
      template:
        name: redis
        componentDef: redis-cluster-8
        serviceVersion: 8.4.0
        replicas: 2
        systemAccounts:
          - name: default
            disabled: false

2. Wait until the Redis cluster becomes Running.

3. Create a Camellia cluster referencing the Redis account Secret:

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: camellia-urxsry
  namespace: default
spec:
  clusterDef: camellia-redis-proxy
  topology: cluster
  terminationPolicy: WipeOut
  componentSpecs:
    - name: camellia-proxy
      replicas: 2
      serviceVersion: 1.4.0
      systemAccounts:
        - name: redis-default
          secretRef:
            name: redisc-urxsry-shard-default
            namespace: default
            password: password
      serviceRefs:
        - name: redis
          namespace: default
          clusterServiceSelector:
            cluster: redisc-urxsry
            service:
              service: shard-secondary
              port: redis-cluster

4. Check the Camellia cluster status:

kubectl get cluster camellia-urxsry

5. Observe that the cluster remains in Creating and no Camellia Pod is created.

Expected behavior

KubeBlocks should automatically resolve the revision of the referenced external account Secret and populate or internally handle secretRefRevision.

The Camellia cluster should proceed with provisioning after the referenced Redis Secret exists and has a valid apps.kubeblocks.io/secret-revision annotation.

Users should only need to specify the external secretRef, rather than manually retrieving and setting the Secret revision.

Screenshots

Not applicable.

Desktop (please complete the following information):

• OS: macOS
• Browser: Not applicable
• Version: Not applicable

Additional context

Environment:

• KubeBlocks version: v1.1.0-beta.10
• Kubernetes version: v1.30.4-vke.4
• Redis service version: 8.4.0
• Camellia service version: 1.4.0

The referenced Secret was valid:

metadata:
  annotations:
    apps.kubeblocks.io/secret-revision: <revision-id>
data:
  username: <redacted>
  password: <redacted>

Adding the revision manually allows the Camellia cluster to start:

secretRefRevision: <revision-id>

This suggests that external account Secret references do not automatically propagate their revision into the consuming Component.

[shanshanying]

The referenced Redis account Secret has a non-empty apps.kubeblocks.io/secret-revision annotation, while the Camellia account omits secretRefRevision. The component controller compares these values unconditionally and keeps requeuing because the consumer revision is empty:

if revision, ok := secret.Annotations[constant.SecretRevisionAnnotationKey]; ok &&
    revision != account.SecretRefRevision {
    return requeue(...)
}

This prevents the Camellia system-account Secret from being generated. Consequently, credentialVarRef cannot find the redis-default credential and reports:

has no Credential object redis-default found when resolving vars

@leon-ape Since secretRefRevision is optional, the controller should probably enforce revision equality only when the consumer explicitly specifies a non-empty revision.

The current workaround is to copy the source Secret’s revision into the consuming account’s secretRefRevision.