Issue 1:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "tarball", "permissions"

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

Kubernetes version (use kubectl version): 1.3.8

Environment:

Cloud provider or hardware configuration: bare metal

OS (e.g. from /etc/os-release): Debian

Kernel (e.g. uname -a): n/a

Install tools: none – custom repackaging

Others:

What happened:

Starting with version 1.3.8, the permissions of all the files in the release tarball (both direct and in the inner tarballs) have changed from 755 to 750 or 644 to 640, resp. I pulled and looked at the permissions of the inner tarballs over a few versions, see this gist.

What you expected to happen:

Files to have stable permissions across versions.

How to reproduce it (as minimally and precisely as possible):

As root, unpack kubernetes.tar.gz. As non-root, try to use any of the binaries.

Anything else do we need to know:

I came across this because we blindly carried the permissions over into our custom repackaging. We do that now, so it's not urgent for us to change anything but it was confusing at first (especially in a patch upgrade). I also don't think there is any reason for this change?

Issue 2:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): no

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubectl, get, export, --export, flag

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

Kubernetes version (use kubectl version):

λ kubectl version
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.7", GitCommit:"a2cba278cba1f6881bb0a7704d9cac6fca6ed435", GitTreeState:"clean", BuildDate:"2016-09-12T23:15:30Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.6", GitCommit:"ae4550cc9c89a593bcda6678df201db1b208133b", GitTreeState:"clean", BuildDate:"2016-08-26T18:06:06Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: GKE

OS (e.g. from /etc/os-release): OS X 10.11.6

Kernel (e.g. uname -a): Darwin ... 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64

Install tools: gcloud

Others:

What happened:

kubectl get --export doesn't strip the cluster specific info from resources (self-links, etc.)

What you expected to happen:

kubectl get --export should provide a cluster-unspecific resource that can be redeployed right away

How to reproduce it (as minimally and precisely as possible):

Anything else do we need to know:

temikus λ kubectl get deployments --export -o=yaml > deploy.yaml
temikus λ kubectl get deployments -o=yaml > deploy_false.yaml
temikus λ diff deploy*
##empty line, should actually be a diff