cybozu-go / accurate

Kubernetes controller for multi-tenancy. It propagates resources between namespaces accurately and allows tenant users to create/delete sub-namespaces.
https://cybozu-go.github.io/accurate/
Apache License 2.0
38 stars 5 forks source link

Pre-existing resources should be upgraded to SSA #120

Closed erikgb closed 6 months ago

erikgb commented 7 months ago

Describe the bug

We have installed the latest version of Accurate (1.3.0), which includes migration to SSA (https://github.com/cybozu-go/accurate/pull/112). While everything seems to work well, we have noticed that pre-existing resources (from before we installed the release with migration to SSA) have some suspicious managedFields. Example for a namespace controlled by a sub-namespace:

managedFields:
  - manager: accurate-controller
    operation: Apply
    apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      'f:metadata':
        'f:annotations':
          'f:collectord.io/index': {}
        'f:labels':
          'f:trust.statnett.no/inject-statnett-bundle': {}
  - manager: accurate-controller
    operation: Update
    apiVersion: v1
    time: '2023-11-08T15:01:07Z'
    fieldsType: FieldsV1
    fieldsV1:
      'f:metadata':
        'f:annotations':
          .: {}
          'f:collectord.io/index': {}
        'f:labels':
          .: {}
          'f:accurate.cybozu.com/parent': {}
          'f:app.kubernetes.io/created-by': {}
          'f:kubernetes.io/metadata.name': {}
          'f:trust.statnett.no/inject-statnett-bundle': {}

This results in unset fields in the SSA patch to retain in the owned resource, which is the issue the migration to SSA PR was supposed to solve (https://github.com/cybozu-go/accurate/issues/98).

Environments

N/A

To Reproduce

Steps to reproduce the behavior:

  1. Install one of the previous versions of Accurate before we migrated to SSA.
  2. Create a SubNamespace adding a label/annotation to the sub-namespace.
  3. Upgrade Accurate to the latest version including migration to SSA
  4. Remove sub-namespace a label/annotation from SubNamespace created in 2.
  5. Observe the label/annotation is still present on sub-namespace.

Expected behavior

The label/annotation removed from SubNamespace spec should be removed from sub-namespace.

Additional context

I know how to fix this and will prepare a PR. 🤠