'kubectl delete istag/$ISTAG --dry-run=server' is unexpectedly deleting the object from the server

[HARSHAL732001]

What happened?

'kubectl delete istag/$ISTAG --dry-run=server' is unexpectedly deleting the object from the server this is not expected behavior.

• Attempted to delete the istag resource object by using the dry-run=server option. However, the object(image) was actually deleted from the server.
• Conversely, when applied the same dry-run=server parameter to other resources, they remained intact and were not deleted.

What did you expect to happen?

After deleting the istag using the --dry-run=server option with the server strategy, the istag object should still remain on the server.

How can we reproduce it (as minimally and precisely as possible)?

Try deleting the istag resource using the --dry-run=server option with the server strategy.

Steps to Reproduce:

1. Example with resource ImageStreamTag istag

• Try to delete the istage object using the --dry-run option with client strategy

[quickcluster@upi-0 ~]$ kubectl delete -n openshift istag/ubi8-openjdk-8:1.11 --dry-run=client
imagestreamtag.image.openshift.io "ubi8-openjdk-8:1.11" deleted (dry run)

• Verify whether the deleted object with client strategy is actually removed or not

[quickcluster@upi-0 ~]$ kubectl get istag -n openshift | grep -i ubi8-openjdk-8:1.11
ubi8-openjdk-8:1.11                                         image-registry.openshift-image-registry.svc:5000/openshift/ubi8-openjdk-8@sha256:022488b1bf697b7dd8c393171a3247bef4ea545a9ab828501e72168f2aac9415                                       4 weeks ago

• Now, delete the istage object using the --dry-run option with server strategy

[quickcluster@upi-0 ~]$ kubectl delete -n openshift istag/ubi8-openjdk-8:1.11 --dry-run=server
imagestreamtag.image.openshift.io "ubi8-openjdk-8:1.11" deleted (server dry run)

• Verify whether the deleted object with server strategy is actually removed or not

[quickcluster@upi-0 ~]$ kubectl get -n openshift istag | grep -i ubi8-openjdk-8:1.11 

2. Example with resource secret

• Try to delete the secret using the --dry-run option with client strategy

[quickcluster@upi-0 ~]$ kubectl delete secrets/deployer-token-jz46t --dry-run=client
secret "deployer-token-jz46t" deleted (dry run)

• Verify whether the deleted object with client strategy is actually removed or not

[quickcluster@upi-0 ~]$ kubectl get secret | grep -i deployer-token-jz46t
deployer-token-jz46t       kubernetes.io/service-account-token   4      28d

• Now, delete the secret using the --dry-run option with server strategy

[quickcluster@upi-0 ~]$ kubectl delete secrets/deployer-token-jz46t --dry-run=server
secret "deployer-token-jz46t" deleted (server dry run)

• Verify whether the deleted object with server strategy is actually removed or not

[quickcluster@upi-0 ~]$ kubectl get secret | grep -i deployer-token-jz46t
deployer-token-jz46t       kubernetes.io/service-account-token   4      28d

Anything else we need to know?

No response

Kubernetes version

$ kubectl version
Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.7+c1f5b34

Cloud provider

OS version

# On Linux:
$ cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.9 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.9 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.9:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.9
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.9"

$ uname -a
Linux upi-0.harshaltest24.lab.psi.pnq2.redhat.com 3.10.0-1160.el7.x86_64 #1 SMP Tue Aug 18 14:50:17 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux

Install tools

``` - oc 4.15 - kubectl v1.28.2 ```

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[neolit123]

/sig cli api-machinery

[ardaguclu]

I think that there is nothing can be done in kubernetes. istag is managed by openshift-apiserver and this issue should go there.

/close

[k8s-ci-robot]

@ardaguclu: Closing this issue.

In response to this:

I think that there is nothing can be done in kubernetes. istag is managed by openshift-apiserver and this issue should go there.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[HARSHAL732001]

Hello @ardaguclu ,

Could you please help me to understand the exact working of --dry-run=server.

--dry-run='none':
	Must be "none", "server", or "client". If client strategy, only print the object that would be sent, without
	sending it. If server strategy, submit server-side request without persisting the resource.

As it says that using --dry-run=server submit server-side request without persisting the resource so does it actually remove the object from server and if yes then how it is different from running --dry-run with client strategy.