No kind \"DeleteOptions\" is registered for version \"admissionregistration.k8s.io/v1\" in scheme

[Sibyl1122]

Describe the bug

when use the "op.#Delete" for deleting custom resource, there is an error happen:
"no kind \"DeleteOptions\" is registered for version \"admissionregistration.k8s.io/v1\" in scheme \"k8s.io/apiextensions-apiserver/pkg/apiserver/apiserver.go:52\""

To Reproduce

Expected behavior

delete target resources successfully and no error be reported

Screenshots

Workflow Version

Cluster information

Additional context

the same value content for listing resourses using op.#List is correct.

[Sibyl1122]

Similar issue： crossplane/crossplane#2284

[FogDong]

I cannot reproduce this in 1.19.15 cluster with v0.3.5 workflow, can you provide a specific workflow step definition and workflowrun?

BTW, my example is as below:

run:

apiVersion: core.oam.dev/v1alpha1
kind: WorkflowRun
metadata:
  name: delete-object
  namespace: default
  annotations:
    "workflowrun.oam.dev/debug": "true"
spec:
  workflowSpec:
    steps:
    - name: deploy
      type: apply-deployment
      properties:
        image: nginx
    - name: delete
      type: delete-object
      properties:
        filter:
          namespace: default
          matchingLabel:
            workflowrun.oam.dev/name: delete-object
        value:
          apiVersion: apps/v1
          kind: Deployment
          metadata:
            namespace: default

cue:

import (
	"vela/op"
)

"delete-object": {
	type: "workflow-step"
	annotations: {
		"category": "Resource Management"
	}
	labels: {}
	description: "Delete kuberentes resource"
}
template: {
	delete: op.#Delete & {
		value: {
			apiVersion: parameter.value.apiVersion
			kind:       parameter.value.kind
			metadata: {
				namespace: parameter.value.metadata.namespace
			}
		}
		filter: {
			namespace:      parameter.filter.namespace
			matchingLabels: parameter.filter.matchingLabels
		}
		cluster: parameter.cluster
	}
	parameter: {
		value: {
			apiVersion: string
			kind:       string
			metadata: {
				name?:     string
				namespace: string
			}
		}
		// +usage=The filter to delete the resources
		filter: {
			// +usage=The namespace to list the resources
			namespace: string
			// +usage=The label selector to filter the resources
			matchingLabels: {...}
		}

		cluster: *"" | string
	}
}

[Sibyl1122]

yaml:

apiVersion: core.oam.dev/v1alpha1
kind: WorkflowRun
metadata:
  name: test-delete
  namespace: default
  annotations:
    workflowrun.oam.dev/debug: "true"
spec:
  workflowSpec:
    steps:
      - name: test-delete
        type: test-delete
        properties:
          podName: hdfshttpfs-286nr-0
          namespace: appworkflow

cue:

import "vela/op"

"test-delete": {
	alias: ""
	annotations: {}
	attributes: {}
	description: ""
	labels: {}
	type: "workflow-step"
}

template: {
	parameter: {
		podName:   string
		namespace: string
	}
	output: {
		del: op.#Delete & {
			value: {
				kind:       "Pod"
				apiVersion: "v1"
				metadata: {
					name:      parameter.podName
					namespace: parameter.namespace
				}
			}
			filter: {
				namespace: parameter.namespace
			}
		}
	}
}

When I tested delete function with the Pod, there is no error reported. But the target pod was not deleted.

[Sibyl1122]

Btw, I also tried the "op.#Delete" without the field "filter". The result was the same as above

[FogDong]

In your case, you wrap the op.#Delete with output, which is redundant, and if it is wrapped without op.#Steps, it will not be executed. That's why in your case the pod is not deleted. But in the future, we'll remove the constraint of actions that must be executed within op.#Steps or the first layer. By now, you can change your definition to:

import "vela/op"

"test-delete": {
	alias: ""
	annotations: {}
	attributes: {}
	description: ""
	labels: {}
	type: "workflow-step"
}

template: {
	parameter: {
		podName:   string
		namespace: string
	}
	del: op.#Delete & {
		value: {
			kind:       "Pod"
			apiVersion: "v1"
			metadata: {
				name:      parameter.podName
				namespace: parameter.namespace
			}
		}
		filter: {
			namespace: parameter.namespace
		}
	}
	fail: op.#Steps & {
		if del.err != _|_ {
			myFail: op.#Fail & {
				message: del.err
			}
		}
	}
}

BTW, with 0.3.5 workflow and 1.19.15 cluster, I still cannot reproduce the problem.🤔

[Sibyl1122]

包了op.steps删除就没问题了，🐮🍺

关于最上面的那个Delete没注册的问题，目前我只在自定义的资源稳定上复现了，同样的代码改成删pod就没问题。不知道是不是因为那个自定义资源底层etcd存储用的是json格式而不是protobuf的问题。
cue:

import "vela/op"

"test-delete": {
	alias: ""
	annotations: {}
	attributes: {}
	description: ""
	labels: {}
	type: "workflow-step"
}

template: {
	parameter: {
		podName:   string
		namespace: string
	}
	output: op.#Steps & {
		del: op.#Delete & {
			value: {
				kind:       "<自定义>"
				apiVersion: "<自定义>/v1alpha1"
				metadata: {
					namespace: parameter.namespace
				}

			}
			filter: {
				namespace: parameter.namespace
				matchingLabels: {
					"targetPod": parameter.podName
				}
			}
		}
		if del.err != _|_ {
			delFail: op.#Fail & {
				message: del.err
			}
		}
	}
}

yaml：

apiVersion: core.oam.dev/v1alpha1
kind: WorkflowRun
metadata:
  name: test-delete-mig
  namespace: default
  annotations:
    workflowrun.oam.dev/debug: "true"
spec:
  workflowSpec:
    steps:
      - name: test-delete
        type: test-delete
        properties:
          podName: mig-jva3bg386j
          namespace: appworkflow

结果：

另外我还尝试了一下：上述删除自定义资源的cue，不加就filter可以成功...怪兮兮的

[FogDong]

上述删除自定义资源的cue，不加就filter可以成功

那是因为加了 filter，走的逻辑是 client.DeleteAll，应该是由于这个函数报错的。

我本地复现会比较困难，或许你可以尝试一下更改本地的控制器，重新注册一下 scheme 看看问题是否解决？

metav1.AddToGroupVersion(s, schema.GroupVersion{Version: "v1"})