<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>.):<br>
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.):<br>
<a href="https://github.com/kubernetes/kubernetes/issues?page=1&amp;q=is%3Aissue+is%3Aopen+rolling+update++ready&amp;utf8=%E2%9C%93">https://github.com/kubernetes/kubernetes/issues?page=1&amp;q=is%3Aissue+is%3Aopen+rolling+update++ready&amp;utf8=%E2%9C%93</a></p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one):<br>
Bug report</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):<br>
1.4.4 client, 1.4.6 cluster</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: GKE</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
Ran <code class="notranslate">kubectl apply -f ...</code>, updating the version for an image.<br>
Observed the existing RS scale to zero before the new RS was ready (the container has a readinessProbe), resulting in downtime.</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
Traffic remains routed to the existing RS until the new RS is ready.</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):<br>
<a href="https://gist.github.com/c82ae5cf2919684926b8bcc23d6ccddc">https://gist.github.com/c82ae5cf2919684926b8bcc23d6ccddc</a></p>
<p dir="auto"><code class="notranslate">kubectl apply -f deployment.yaml</code></p>
<p dir="auto">Wait for it to start serving.<br>
Modify something like the "env" in deployment.yaml<br>
Run <code class="notranslate">kubectl apply</code>.</p>
<p dir="auto">Observe that the old RC is immediately scaled to zero.</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:<br>
N/A</p>
<p dir="auto">APIGroups are a really useful features, but there are several areas of the code that need improvement to make their usage easier to understand.  These are few things I found while trying to reliably activate and configure the <code class="notranslate">extensions</code> group downstream</p>
<ol dir="auto">
<li>We need a <code class="notranslate">GroupVersion</code> object to make it very obvious in the code when a bit of code relies on that.  Right now, sometimes its two strings, sometimes its one string to split, sometimes objects hold both.</li>
<li>Validation is needed when starting a master to make sure that combination of <code class="notranslate">StorageDestinations</code>, <code class="notranslate">apiGroupVersionOverrides</code>, <code class="notranslate">storageVersions</code>, and the available <code class="notranslate">Groups</code> makes sense.  I suspect that there's a cleaner factorization.</li>
<li>DONE Functions like <code class="notranslate">InterfacesFor</code> need to decide if they take <code class="notranslate">GroupVersion</code> or just an API version.  I'm ok with either one, but right now you get things like an error message saying <code class="notranslate">unsupported storage version: v1beta1 (valid: v1beta1)</code> because part of the code thinks its a version and part of it thinks its a <code class="notranslate">GroupVersion</code>.</li>
<li>REST APIVersions are unrelated to storage APIVersions.  Right now, the REST preferred version is tied to the storage version.</li>
<li>Reporting throughout the stack should understand that <code class="notranslate">Kind</code> strings are no longer unambiguous.  Types like <code class="notranslate">StatusDetails</code> should accept an <code class="notranslate">APIGroup</code> as well.</li>
<li>Registrations of <code class="notranslate">GroupMeta</code> shouldn't be mutable.  I don't see why we'd ever want it mutable and its kind of crazy to change it part way through.</li>
<li>DONE (well, differently in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="112685544" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/16062" data-hovercard-type="pull_request" data-hovercard-url="/kubernetes/kubernetes/pull/16062/hovercard" href="https://github.com/kubernetes/kubernetes/pull/16062">#16062</a>) Type registration and lookups seems to be split across three packages (<code class="notranslate">install</code>, <code class="notranslate">registered</code>, <code class="notranslate">latest</code>), all of which try to take APIGroups into account.  This needs reorganization.  Perhaps we could try a layered approach where <code class="notranslate">latest</code> is scoped to versions of a single APIGroup, <code class="notranslate">install</code> is responsible for handling registration with a <code class="notranslate">registered</code> package which is the source of truth for all metadata.  No other package should expose cross group metadata.</li>
<li>Having combined clients makes it harder to trace the effects of disabling an APIGroup and risks potential name collisions going forward.  Splitting Clients on APIGroups seems reasonable.</li>
</ol>
<p dir="auto">One of the things that may help with factorization is trying to describe the existing <code class="notranslate">v1</code> API as an GroupVersion("", "v1") throughout all of the code.  If its hard to read like that, then there's probably a factorization problem.</p>
<p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/caesarxuchao/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/caesarxuchao">@caesarxuchao</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/smarterclayton/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/smarterclayton">@smarterclayton</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/liggitt/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/liggitt">@liggitt</a> @kubernetes/kube-api</p>