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
- 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 }}'
- 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
- 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
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:
NetworkAPIVirtualMachineAPI that allows you to reference an existingNetwork(defined as related resource) in which the virtual machine should be createdIn this case, both api-syncagents add the finalizer "syncagent.kcp.io/cleanup" to any
Networkobject referenced by aVirtualMachine- the api-syncagent of service provider "A" since theNetworkis the primary object, the api-syncagent of service provider "B" since theNetworkobject is a related resource withorigin: kcp.When a
VirtualMachineis deleted, provider "B" removes the finalizer from theNetworkas part of cleanup — but provider "A" immediately re-adds it, blocking deletion indefinitely.Steps To Reproduce
PublishedResourceforNetworkDetails
PublishedResourceforVirtualMachineDetails
APIExports, apply manifests, and deleteVirtualMachineDetails
Expected Behaviour
The
VirtualMachineshould get deleted successfullyAdditional Context