<p dir="auto">The following is a proposal for reworking the existing <code class="notranslate">kube-up.sh</code>, <code class="notranslate">kube-down.sh</code>, and <code class="notranslate">kube-push.sh</code> to eventually be in Go for advanced cloud deployments, while allowing the existing shell investment to continue for a period of time.</p>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Define a <code class="notranslate">deploy/deploycmd/api</code> versioned <code class="notranslate">Cluster</code> object. This object holds all general configuration variables of the cluster and the add-on pods, plus IAAS relevant variables specific to each IAAS provider. (Issue to be filed soon to haggle over what's in these structures.)</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Create a <code class="notranslate">kubedeploy</code> command with <code class="notranslate">up</code>, <code class="notranslate">down</code>, and <code class="notranslate">push</code> verbs, each of which take a cluster YAML. The <code class="notranslate">up</code> and <code class="notranslate">push</code> verbs take a path (possibly optional in the case of <code class="notranslate">push</code>) to the Kubernetes binaries to deploy.</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> The initial implementation of <code class="notranslate">kubedeploy</code> only has to act as a YAML -&gt; env variable translator. Re-write the existing shell scripts to use common env variables (they're actually all close, e.g. <code class="notranslate">config-default.sh</code>, etc.). Then <code class="notranslate">kubedeploy</code> can take the given API object, spew a chunk of environment variables, and carefully execute the existing bash scripts (<em>vigorous handwaving</em>, but this part is not that technically challenging, just a hairy yak).</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> We can then define the interfaces in Go for what an "enlightened" deployment looks like, and in the process try to transition the GCE cloud provider over (keeping an eye on, say, Vagrant as the N=2 case.)</li>
</ul>
<p dir="auto">As an added benefit, the last bullet gives us a place to start upstreaming GKE cluster deployment code, which has been a desire for the GKE team for a while. Oh, and <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/satnam6502/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/satnam6502">@satnam6502</a> will probably love it for scalability, because I think he gouges his eyes out every time he deals with the bash in <code class="notranslate">util.sh</code>.</p>
<p dir="auto">This will also give us a place for <code class="notranslate">kubedeploy upgrade</code> in the fullness of time, which is a distinct use case from <code class="notranslate">push</code>.</p>
<p dir="auto">Thoughts?</p>
<p dir="auto">cc <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/jlowdermilk/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/jlowdermilk">@jlowdermilk</a>, <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/brendandburns/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/brendandburns">@brendandburns</a>, <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/alex-mohr/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/alex-mohr">@alex-mohr</a>, and anyone else that cares.</p>
<p dir="auto"><a href="https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/kubelet-gce-e2e-ci/8886/" rel="nofollow">https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/kubelet-gce-e2e-ci/8886/</a></p>
<p dir="auto">Failed: [k8s.io] Container Runtime Conformance Test container runtime conformance blackbox test when running a container with a new image should be able to pull image from docker hub {E2eNode Suite}</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="/var/lib/jenkins/workspace/kubelet-gce-e2e-ci/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e_node/runtime_conformance_test.go:290
Timed out after 300.000s.
Expected
    &lt;bool&gt;: false
to be true
/var/lib/jenkins/workspace/kubelet-gce-e2e-ci/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e_node/runtime_conformance_test.go:281"><pre class="notranslate"><code class="notranslate">/var/lib/jenkins/workspace/kubelet-gce-e2e-ci/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e_node/runtime_conformance_test.go:290
Timed out after 300.000s.
Expected
    &lt;bool&gt;: false
to be true
/var/lib/jenkins/workspace/kubelet-gce-e2e-ci/go/src/k8s.io/kubernetes/_output/local/go/src/k8s.io/kubernetes/test/e2e_node/runtime_conformance_test.go:281
</code></pre></div>