Issue 1:
Given a kubernetes cluster that is running some number of pods, services, deployments, etc, I would like to generate one or more files ( yml format preferred) that would re-produce the current configuration, when applied to a new cluster.

My use case is a promotion system. I have my 'stack files' as yml files in a git repo, but I need to allow humans to approve changes before they are applied to the cluster.

One way to do this is to use an 'open loop' system. I can use tags or other mechanisms to determine which versions have been applied to the cluster, and then compare the latest version available with the latest deployed version.

The problem with the open-loop system is that it does not consider that changes could have been made outside the files, or that changes applied could have had problems, etc.

If I could extract the 'equivalent' files from a running cluster, I could compare them with the ones that are about to be applied. This is a much stronger, 'closed loop' system-- it is able to correctly understand what will happen when the changes are applied, even if we have lost track of the real target state.

if there were such a thing as kubectl apply -f --dry-run, which lists only the changes that will be made, rather than actually doing the changes, that would work as well. That is already being discussed over at issue #11488

Does anyone have thoughts on this? We are new to kubernetes, but we have created the the functionality I'm describing above for our RedHat/Satellite rpm-based deployments, so i want to re-create it in K8s. Of course, in k8s, we have the complexity that the infrastructure itself can change, not just installed package versions!

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.): zsh

(Found a bug which I believe is a consequence of this bug, will mark it as such after filed)

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

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.5", GitCommit:"b0deb2eb8f4037421077f77cb163dbb4c0a2a9f5", GitTreeState:"clean", BuildDate:"2016-08-11T20:29:08Z", 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: GCE kubernetes

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

Kernel (e.g. uname -a): Darwin tungsten.local 14.5.0 Darwin Kernel Version 14.5.0: Mon Aug 29 21:14:16 PDT 2016; root:xnu-2782.50.6~1/RELEASE_X86_64 x86_64

Install tools:

Others:

What happened:

Calling source <( kubectl completion zsh) did a re-init of the completion system, stomping over any settings already applied (alternative cache file locations, etc) and causing debugging problems. (The gcloud SDK makes the same mistake).

What you expected to happen:

Define completions but don't call compinit which is a top-level command for completion system initialization which should only be called once and should not be called from within the completion definitions for a given command.

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

ZDOTDIR=/some/path
. <( kubectl completion zsh)
ls -ld $ZDOTDIR/.zcompdump

Anything else do we need to know:

My current shell config workaround is to call:

<( kubectl completion zsh | grep -v '^autoload .*compinit$' )

Note that the GCloud completion.zsh.inc makes the same mistake, so needs to be edited to avoid the system initialization function to avoid triggering the bug there too.

Ideally the calls to compinit/bashcompinit would just be removed, but if there are user-support concerns from people who haven't otherwise enabled completion then you might be able to get away with "force-enable completion with defaults unless already enabled". In which case, this should work:

zmodload -i zsh/parameter
if ! (( $+functions[compdef] )) ; then
autoload -U +X compinit && compinit
autoload -U +X bashcompinit && bashcompinit
fi

This works because compinit is explicitly documented to provide the function compdef after called; the zsh/parameter loadable module provides the functions special associative array. zsh/parameter will frequently have been loaded anyway, making the zmodload a no-op safety check (loadable modules are safe to request repeatedly, it's idempotent, unlike compinit).