external-secrets icon indicating copy to clipboard operation
external-secrets copied to clipboard

"owned by another ExternalSecret controller" condition is not reevaluated

Open PeterStolz opened this issue 1 year ago • 2 comments

Describe the bug I have 2 external secrets that had the same target.name. Now one of them correctly has status SecretsSyncedError with the message could not set ExternalSecret controller reference: Object default/s3-access is already owned by another ExternalSecret controller service-uris.

However when editing the conflicting resource service-uris to have a different target.name, the secret s3-access is properly removed. Now I would expect the failed ExternalSecret to fix itself as it has no blockers anymore and could create the secret s3-access. When I recreated the ExternalSecret it worked. It just could not recover on its own.

To Reproduce Steps to reproduce the behavior:

  • Have a valid SecretStore
  • Create 2 ExternalSecrets with the same target.name
  • Edit (not replace) target.name on the ExternalSecret that created the secret
  • Observe that the target secret name indeed did change
  • The ExternalSecret that failed should repair itself, as it could create its target secret
  1. provide all relevant manifests unfortunately I deployed via argocd and don't have the old manifest. If needed I can try to reproduce it again locally
  2. provide the Kubernetes and ESO version Kubernetes 1.26 ESO version 0.9.13

Expected behavior I would expect an ExternalSecret to regularly check if the reason it was blocked still exists. In this case it might be because the blocking resource still existed but the target.name was changed such that it would be possible to create the secret again.

PeterStolz avatar Feb 26 '24 13:02 PeterStolz

Hi, @PeterStolz When reconcile failed, it returns an empty result, which has no RequeueAfter. It triggers the default exponential backoff strategy of k8s controller-runtime. If you wait for long enough time, the failed ExternalSecret will fix itself.

I think add a field backoffIntervalTime(not exit at present) to ExternalSecret and ClusterExternalSecret is helpful in such case:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: example
spec:
  backoffRefreshInterval: 10s
  refreshInterval: 1h
  secretStoreRef:
    name: secretstore-sample
    kind: SecretStore
  target:
    name: secret-to-be-created
    creationPolicy: Owner
  data:
  - secretKey: secret-key-to-be-managed
    remoteRef:
      key: provider-key
      version: provider-key-version
      property: provider-key-property
  dataFrom:
  - extract:
      key: remote-key-in-the-provider

Hayden-Chang avatar Mar 11 '24 04:03 Hayden-Chang

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.

github-actions[bot] avatar Jun 18 '24 01:06 github-actions[bot]

This issue was closed because it has been stalled for 30 days with no activity.

github-actions[bot] avatar Aug 02 '24 01:08 github-actions[bot]