kubectl apply: prune should ignore no-namespaced resource if -n is not empty

[pacoxu]

kubectl apply with below yaml and follow below prune command.

**
namespace sandbox
**
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    environment: sandbox
    provider: kustomize
  labels:
    app: nginx
  name: nginx
  namespace: sandbox
spec:
  ports:
  - port: 80
  selector:
    app: nginx
  type: NodePort

seems I have the same problem. save this to a file named a.yaml

apiVersion: v1
kind: Service
metadata:
  annotations:
    environment: sandbox
    provider: kustomize
  labels:
    app: nginx
  name: nginx
  namespace: sandbox
spec:
  ports:
  - port: 80
  selector:
    app: nginx
  type: NodePort

And run kubectl apply --prune --dry-run=client --all -n sandbox -f a.yaml, the results

service/nginx created (dry run)
namespace/cattle-system pruned (dry run)

I have no idea why it want to prune the namespace/cattle-system.

Originally posted by @wd in #66430 (comment)

[pacoxu]

I prefer to think this is a bug of kubectl.

/kind bug
/sig cli

[harry1064]

Hi @pacoxu

I was looking at the test cases for prune inside apply_test.go, seems like it never goes inside the pruning logic.
https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kubectl/pkg/cmd/apply/apply_test.go#L584-L632
as we are not setting up fakeDynamicClient to handle list request for the resource under test.

Should we fix the test case as well? I have tried to setup the fakeDynamicClient and register some reactor to respond to list and delete requests. With some data alterations able to get the prune logic executed.

[pacoxu]

@harry1064 We may add some in separate pr.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[pacoxu]

/remove-lifecycle stale
There are some discussions in pr and sig meetings. I will update the pr ASAP.

[KnVerey]

/triage accepted
The deprecation warning on the current behaviour made it into 1.26 yesterday, so we'll be able to change it in 1.28 or later.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[m-Bilal]

May I take this up?

[manav014]

/assign

[m-Bilal]

Hi @manav014 , are you working on this? (I was intending to work on this issue, hence the comment)

[manav014]

Hey @m-Bilal , If you are working on this, you can take that forward and assign yourself. I will check out some other issues.

[m-Bilal]

@manav014 sorry I should have been clearer. I haven't started yet. So if you have started, that's fine, I can look into another one. If not, then I'm happy to take this up 😄

[manav014]

@m-Bilal I started with that. I will share what am I planning and other research, we can collaborate on this. You can help me with optimizations and feedback. If that sounds good to you.

[pacoxu]

#110907 was merged in v1.26

• kubectl apply: warning that kubectl will ignore no-namespaced resource pv & namespace in a future release if the namespace is specified and allowlist is not specified

kubernetes/staging/src/k8s.io/kubectl/pkg/util/prune/prune.go

Lines 66 to 73 in 3ce7cdd

	if len(pruneResources) == 0 {
	pruneResources = defaultNamespacedPruneResources
	// TODO in kubectl v1.29, add back non-namespaced resource only if namespace is not specified
	pruneResources = append(pruneResources, defaultNonNamespacedPruneResources...)
	if namespaceSpecified {
	klog.Warning("Deprecated: kubectl apply will no longer prune non-namespaced resources by default when used with the --namespace flag in a future release. To preserve the current behaviour, list the resources you want to target explicitly in the --prune-allowlist flag.")
	}
	}

[vaibhav2107]

/remove-lifecycle stale

[pacoxu]

This can be done in v1.29 release cycle.

The TODO can be fixed.

kubernetes/staging/src/k8s.io/kubectl/pkg/util/prune/prune.go

Lines 68 to 72 in d25c0a1

	// TODO in kubectl v1.29, add back non-namespaced resource only if namespace is not specified
	pruneResources = append(pruneResources, defaultNonNamespacedPruneResources...)
	if namespaceSpecified {
	klog.Warning("Deprecated: kubectl apply will no longer prune non-namespaced resources by default when used with the --namespace flag in a future release. To preserve the current behaviour, list the resources you want to target explicitly in the --prune-allowlist flag.")
	}

[pacoxu]

/help
/good-first-issue

[k8s-ci-robot]

@pacoxu:
This request has been marked as suitable for new contributors.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/help
/good-first-issue

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/test-infra repository.

[vaibhav2107]

I'd like to work on this issue
/assign

[Affan-7]

seems I have the same problem. save this to a file named a.yaml

apiVersion: v1
kind: Service
metadata:
  annotations:
    environment: sandbox
    provider: kustomize
  labels:
    app: nginx
  name: nginx
  namespace: sandbox
spec:
  ports:
  - port: 80
  selector:
    app: nginx
  type: NodePort

And run kubectl apply --prune --dry-run=client --all -n sandbox -f a.yaml, the results

service/nginx created (dry run)
namespace/cattle-system pruned (dry run)

I have no idea why it want to prune the namespace/cattle-system.

Originally posted by @wd in #66430 (comment)

Hi @pacoxu I can't reproduce this.

[Affan-7]

The TODO can be fixed.

Can you please elaborate more on that. What is the current behaviour and what is the expected behaviour of prune.

[Affan-7]

I would love to work on this issue. (This is my first issue in this repository)
/assign

[pacoxu]

The TODO can be fixed.

Can you please elaborate more on that. What is the current behaviour and what is the expected behaviour of prune.

I edited the description. Can you try again?

[Affan-7]

I edited the description. Can you try again?

Still can't reproduce.

[pacoxu]

I mean that test namespace is created by apply. If the test namespace is not created by the apply, it will never be handle by apply --prune. In this case, you should put the test namespace yaml to the a.yaml with the service yaml.

1. The first apply will create the ns and service.
2. Then remove the namespace yaml from the a.yaml
3. The second apply with --prune -n test will remove the namespace.

[pacoxu]

See #119687 (comment). There is a bug in previous implementation with my PR #110907.

[arushdesp]

Hi all,
Did anyone managed to solve it or you still need help? I tried to replicated it for the testing in k8s v1.27 cause i wanted to try solving it and i had the following result:
After creating namespace and pod in my next run with prune I had the specific error message:

kubectl apply --prune --dry-run=client --all -n dev -f nginx.yaml
namespace/dev configured (dry run)
pod/nginxns configured (dry run)
W0428 01:54:39.696986 4304 prune.go:71] Deprecated: kubectl apply will no longer prune non-namespaced resources by default when used with the --namespace flag in a future release. To preserve the current behaviour, list the resources you want to target explicitly in the --prune-allowlist flag.

[pacoxu]

After creating namespace and pod in my next run with prune I had the specific error message:

This is a warning message, not an error message.