Skip to content

bug: finalizer "syncagent.kcp.io/cleanup" on related resources block deletion of primary object #172

Description

@dakraus

Describe the bug

Let's assume, there are two service providers using the api-syncagent to publish API resources and sync objects to / from kcp. To have a concrete example, let's also assume that:

  • service provider "A" provides a Network API
  • service provider "B" provides a VirtualMachine API that allows you to reference an existing Network (defined as related resource) in which the virtual machine should be created

In this case, both api-syncagents add the finalizer "syncagent.kcp.io/cleanup" to any Network object referenced by a VirtualMachine - the api-syncagent of service provider "A" since the Network is the primary object, the api-syncagent of service provider "B" since the Network object is a related resource with origin: kcp.

When a VirtualMachine is deleted, provider "B" removes the finalizer from the Network as part of cleanup — but provider "A" immediately re-adds it, blocking deletion indefinitely.

Steps To Reproduce

  1. service provider "A": install api-syncagent and created PublishedResource for Network
Details
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: networks.network.example.com
spec:
  group: network.example.com
  names:
    kind: Network
    listKind: NetworkList
    plural: networks
    singular: network
  scope: Namespaced
  versions:
  - name: v1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              cidrBlock:
                type: string
    served: true
    storage: true
---
apiVersion: syncagent.kcp.io/v1alpha1
kind: PublishedResource
metadata:
  name: networks.network.example.com
spec:
  resource:
    apiGroup: network.example.com
    versions: [v1]
    kind: Network
  naming:
    namespace: 'ws-{{ .ClusterName }}-{{ .Object.metadata.namespace | sha3short }}'
    name: '{{ .Object.metadata.name }}'
  1. service provider "B": install api-syncagent and created PublishedResource for VirtualMachine
Details
---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: virtualmachines.compute.example.com
spec:
  group: compute.example.com
  names:
    kind: VirtualMachine
    listKind: VirtualMachineList
    plural: virtualmachines
    singular: virtualmachine
  scope: Namespaced
  versions:
  - name: v1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              networkRef:
                type: object
                properties:
                  name:
                    type: string
    served: true
    storage: true
---
apiVersion: syncagent.kcp.io/v1alpha1
kind: PublishedResource
metadata:
  name: virtualmachines.compute.example.com
spec:
  resource:
    apiGroup: compute.example.com
    versions: [v1]
    kind: VirtualMachine
  naming:
    namespace: 'ws-{{ .ClusterName }}-{{ .Object.metadata.namespace | sha3short }}'
    name: '{{ .Object.metadata.name }}'
  related:
    - identifier: network
      origin: kcp
      group: network.example.com
      version: v1
      resource: networks
      identityHash: ${NETWORKS_API_EXPORT_IDENTITY_HASH}
      object:
        reference:
          path: spec.networkRef.name
  1. consumer: bind both APIExports, apply manifests, and delete VirtualMachine
Details
---
apiVersion: network.example.com/v1
kind: Network
metadata:
  name: network
spec:
  cidrBlock: "192.168.0.0/24"
---
apiVersion: compute.example.com/v1
kind: VirtualMachine
metadata:
  name: vm
spec:
  networkRef:
    name: network

Expected Behaviour

The VirtualMachine should get deleted successfully

Additional Context

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugCategorizes issue or PR as related to a bug.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions