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 "--dry-run" with "-o yaml" does not show 'apiVersion' neither 'kind' #384

Closed
carlosrmendes opened this issue Mar 29, 2018 · 11 comments
Assignees

Comments

@carlosrmendes
Copy link

carlosrmendes commented Mar 29, 2018

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version): 1.10.0

Environment:

  • Cloud provider or hardware configuration: baremetal
  • OS (e.g. from /etc/os-release): centos 7
  • Kernel (e.g. uname -a): 3.10.0-693.17.1.el7.x86_64
  • Install tools: kubeadm
  • Others:

What happened:
the output of kubectl create namespace my-namespace -o yaml --dry-run does not show 'apiVersion' neither 'kind' as previous versions.
kubectl create namespace my-namespace -o yaml --dry-run
Output:
metadata:
creationTimestamp: null
name: my-namespace
spec: {}
status: {}

What you expected to happen:
expected the output of previous versions, like:
$ kubectl create namespace my-namespace -o yaml --dry-run
Output:
apiVersion: v1
kind: Namespace
metadata:
creationTimestamp: null
name: my-namespace
spec: {}
status: {}

I use the "--dry-run" and "-o yaml" to execute kubectl create namespace my-namespace -o yaml --dry-run | kubectl apply -f -

@nikhita
Copy link
Member

nikhita commented Apr 1, 2018

Can you tell what kubectl version gives you?

I tried both for:

Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.1-beta.0.17+a22f9fd34871d9", GitCommit:"a22f9fd34871d9dc9e5db2c02c713821d18ab2cd", GitTreeState:"clean", BuildDate:"2018-04-01T13:05:59Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.1-beta.0.17+a22f9fd34871d9", GitCommit:"a22f9fd34871d9dc9e5db2c02c713821d18ab2cd", GitTreeState:"clean", BuildDate:"2018-04-01T13:05:59Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

and

Client Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.1947+11d28128a71942", GitCommit:"11d28128a719427373a059d10c9407b930f2b324", GitTreeState:"clean", BuildDate:"2018-04-01T12:50:20Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11+", GitVersion:"v1.11.0-alpha.0.1947+11d28128a71942", GitCommit:"11d28128a719427373a059d10c9407b930f2b324", GitTreeState:"clean", BuildDate:"2018-04-01T12:50:20Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

and it gives me the correct output.

$ kubectl create namespace my-namespace -o yaml --dry-run
apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: null
  name: my-namespace
spec: {}
status: {}

@carlosrmendes
Copy link
Author

carlosrmendes commented Apr 2, 2018

fresh install on centos 7.4: yum install kubelet kubeadm kubectll

kubectl version

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:55:54Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

kubectl create namespace my-namespace -o yaml --dry-run

metadata:
  creationTimestamp: null
  name: my-namespace
spec: {}
status: {}

@mikedoug
Copy link

mikedoug commented Apr 4, 2018

I too had this problem with:

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:55:54Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-26T16:44:10Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
# kubectl create namespace my-namespace -o yaml --dry-run
metadata:
  creationTimestamp: null
  name: my-namespace
spec: {}
status: {}

@everydaynerd
Copy link

Having same issue with Version 1.10.0 - This is breaking a lot of our build jobs... 👎

@mikedoug
Copy link

mikedoug commented Apr 4, 2018

You can work around it by injecting:

apiVersion: v1
kind: <typehere>

I ran into this with Istio's installation script for auto injecting the side car. It was one location in one script, so this type of work around didn't hurt too badly.

@mikedoug
Copy link

mikedoug commented Apr 4, 2018

If you look at the version of 1.10 @nikhita is running she's on a beta release of 1.10.1 -- so perhaps there's a fix already coming. Those of us affected are using the current stable release of 1.10.0.

@jsenon
Copy link

jsenon commented Apr 4, 2018

still have issue with 1.10.1 beta:

./kubectl.dms create namespace my-namespace -o yaml --dry-run
metadata:
  creationTimestamp: null
  name: my-namespace
spec: {}
status: {}
./kubectl.dms version
Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.1-beta.0", GitCommit:"75861c097c6499acc662c1094b3e95de851bd87a", GitTreeState:"clean", BuildDate:"2018-03-26T17:27:29Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}

@nikhita
Copy link
Member

nikhita commented Apr 4, 2018

This was fixed in kubernetes/kubernetes#61808. This patch was cherry-picked into release-1.10 - kubernetes/kubernetes#61836.

The latest 1.10 tag is v1.10.1-beta.0, which was created 9 days ago. This patch was merged 6 days ago into the 1.10 branch. It should be there on the next released tag.

(Also, it worked for me above because I was on the release-1.10 branch)

@nikhita
Copy link
Member

nikhita commented Apr 4, 2018

Just confirmed with sig-release, 1.10.1 should be out mid next week.

@jsenon
Copy link

jsenon commented Apr 5, 2018

That’s clear thanks

@nikhita
Copy link
Member

nikhita commented Apr 5, 2018

Closing this since the fix has been merged on master and cherry-picked.

/close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants