<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">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 <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="95764950" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/11488" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/11488/hovercard" href="https://github.com/kubernetes/kubernetes/issues/11488">#11488</a></p>
<p dir="auto">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!</p>
<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.): No</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.): zsh</p>
<p dir="auto">(Found a bug which I believe is a consequence of this bug, will mark it as such after filed)</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one): BUG REPORT</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):</p>
<p dir="auto">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"}<br>
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"}</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: GCE kubernetes</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): MacOS 10.10.5</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>): 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</li>
<li><strong>Install tools</strong>:</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:</p>
<p dir="auto">Calling <code class="notranslate">source &lt;( kubectl completion zsh)</code> 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).</p>
<p dir="auto"><strong>What you expected to happen</strong>:</p>
<p dir="auto">Define completions but don't call <code class="notranslate">compinit</code> 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.</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="ZDOTDIR=/some/path
. &lt;( kubectl completion zsh)
ls -ld $ZDOTDIR/.zcompdump"><pre class="notranslate"><code class="notranslate">ZDOTDIR=/some/path
. &lt;( kubectl completion zsh)
ls -ld $ZDOTDIR/.zcompdump
</code></pre></div>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto">My current shell config workaround is to call:</p>
<p dir="auto"><code class="notranslate">&lt;( kubectl completion zsh | grep -v '^autoload .*compinit$' )</code></p>
<p dir="auto">Note that the GCloud <code class="notranslate">completion.zsh.inc</code> makes the same mistake, so needs to be edited to avoid the system initialization function to avoid triggering the bug there too.</p>
<p dir="auto">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 <em>might</em> be able to get away with "force-enable completion with defaults unless already enabled".  In which case, this should work:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="zmodload -i zsh/parameter
if ! (( $+functions[compdef] )) ; then
  autoload -U +X compinit &amp;&amp; compinit
  autoload -U +X bashcompinit &amp;&amp; bashcompinit
fi"><pre class="notranslate"><code class="notranslate">zmodload -i zsh/parameter
if ! (( $+functions[compdef] )) ; then
  autoload -U +X compinit &amp;&amp; compinit
  autoload -U +X bashcompinit &amp;&amp; bashcompinit
fi
</code></pre></div>
<p dir="auto">This works because <code class="notranslate">compinit</code> is explicitly documented to provide the function <code class="notranslate">compdef</code> after called; the <code class="notranslate">zsh/parameter</code> loadable module provides the <code class="notranslate">functions</code> special associative array.  <code class="notranslate">zsh/parameter</code> will frequently have been loaded anyway, making the <code class="notranslate">zmodload</code> a no-op safety check (loadable modules are safe to request repeatedly, it's idempotent, unlike <code class="notranslate">compinit</code>).</p>