Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kubectl apply set-last-applied does not use manifest's metadata.namespace #787

Closed
migueloller opened this issue Dec 16, 2019 · 9 comments
Closed
Assignees
Labels
area/kubectl kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/P1 sig/cli Categorizes an issue or PR as relevant to SIG CLI.

Comments

@migueloller
Copy link

migueloller commented Dec 16, 2019

What happened

Running kubectl apply set-last-applied after successfully running kubectl apply fails with message: Error from server (NotFound): .... The reason for this is that while kubectl apply uses the manifests' metadata.namespace to update the resources, kubectl apply set-last-applied uses the default namespace for the current context of the kubeconfig.

Expected Behavior

kubectl apply set-last-applied should use the manifests' metadata.namespace just like kubectl apply does.

Reproduction

test-svc.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: test
---
apiVersion: v1
kind: Service
metadata:
  name: test-svc
  namespace: test
spec:
  type: ExternalName
  externalName: www.example.com
kubectl config set-context --current --namespace=default
kubectl apply -f ./test-svc.yaml
kubectl apply set-last-applied -f ./test-svc.yaml
@seans3
Copy link
Contributor

seans3 commented Dec 16, 2019

Thanks for the reproduction steps--very useful. Could you add the version of the client and server (run kubectl version). Thanks.

/sig cli
/area kubectl
/kind bug
/priority P1
/assign

@k8s-ci-robot k8s-ci-robot added sig/cli Categorizes an issue or PR as relevant to SIG CLI. area/kubectl kind/bug Categorizes issue or PR as related to a bug. priority/P1 labels Dec 16, 2019
@migueloller
Copy link
Author

kubectl version

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-13T11:52:32Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:09:08Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

Note: Reproduction was done in minikube.

minikube version

minikube version: v1.6.1
commit: 42a9df4854dcea40ec187b6b8f9a910c6038f81a

@zhouya0 zhouya0 removed their assignment Dec 17, 2019
@zhouya0
Copy link
Contributor

zhouya0 commented Dec 17, 2019

Actually you can use specify kubectl apply set-last-applied -f ./test-svc.yaml -n test to solve this problem.

But if you want to change this command without specify -n. Perhaps we have to change code:
https://github.com/kubernetes/kubernetes/blob/42fe74cd2c2d09a5fa80976bb82c91caa778738e/staging/src/k8s.io/kubectl/pkg/cmd/apply/apply_set_last_applied.go#L209
o.namespace into info.namespace

@migueloller
Copy link
Author

@zhouya0,

Actually you can use specify kubectl apply set-last-applied -f ./test-svc.yaml -n test to solve this problem.

That is correct. This is a simple example but manifest files may contain resources that are deployed to different namespaces. In this case, specifying --namespace would result in an error. I think it's also fair to expect kubectl apply last-applied-configuration to behave like kubectl apply.

But if you want to change this command without specify -n. Perhaps we have to change code:
https://github.com/kubernetes/kubernetes/blob/42fe74cd2c2d09a5fa80976bb82c91caa778738e/staging/src/k8s.io/kubectl/pkg/cmd/apply/apply_set_last_applied.go#L209
o.namespace into info.namespace

Seems easy enough. Happy to open a PR if it's something that would be welcome.

@ricochet
Copy link
Contributor

This will be resolved by server-side apply.

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 21, 2020
@brianpursley
Copy link
Member

Confirmed this is resolved in kubectl 1.18.0.

Using kubectl 1.17.3:

$ kubectl apply set-last-applied -f ./test-svc.yaml
namespace/test configured
Error from server (NotFound): services "test-svc" not found

Using kubectl 1.18.0:

$ kubectl apply set-last-applied -f ./test-svc.yaml
namespace/test configured
service/test-svc configured

@brianpursley
Copy link
Member

Closing because this has been fixed.
/close

@k8s-ci-robot
Copy link
Contributor

@brianpursley: Closing this issue.

In response to this:

Closing because this has been fixed.
/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/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kubectl kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. priority/P1 sig/cli Categorizes an issue or PR as relevant to SIG CLI.
Projects
None yet
Development

No branches or pull requests

7 participants