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

https://github.com/kubernetes/kubernetes/issues?page=1&q=is%3Aissue+is%3Aopen+rolling+update++ready&utf8=%E2%9C%93

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

Bug report

Kubernetes version (use kubectl version):

1.4.4 client, 1.4.6 cluster

Environment:

Cloud provider or hardware configuration: GKE

What happened:

Ran kubectl apply -f ..., updating the version for an image.

Observed the existing RS scale to zero before the new RS was ready (the container has a readinessProbe), resulting in downtime.

What you expected to happen:

Traffic remains routed to the existing RS until the new RS is ready.

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

https://gist.github.com/c82ae5cf2919684926b8bcc23d6ccddc

kubectl apply -f deployment.yaml

Wait for it to start serving.

Modify something like the "env" in deployment.yaml

Run kubectl apply.

Observe that the old RC is immediately scaled to zero.

Anything else do we need to know:

N/A

Issue 2:
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 extensions group downstream

We need a GroupVersion 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.

Validation is needed when starting a master to make sure that combination of StorageDestinations, apiGroupVersionOverrides, storageVersions, and the available Groups makes sense. I suspect that there's a cleaner factorization.

DONE Functions like InterfacesFor need to decide if they take GroupVersion or just an API version. I'm ok with either one, but right now you get things like an error message saying unsupported storage version: v1beta1 (valid: v1beta1) because part of the code thinks its a version and part of it thinks its a GroupVersion.

REST APIVersions are unrelated to storage APIVersions. Right now, the REST preferred version is tied to the storage version.

Reporting throughout the stack should understand that Kind strings are no longer unambiguous. Types like StatusDetails should accept an APIGroup as well.

Registrations of GroupMeta 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.

DONE (well, differently in #16062) Type registration and lookups seems to be split across three packages (install, registered, latest), all of which try to take APIGroups into account. This needs reorganization. Perhaps we could try a layered approach where latest is scoped to versions of a single APIGroup, install is responsible for handling registration with a registered package which is the source of truth for all metadata. No other package should expose cross group metadata.

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.

One of the things that may help with factorization is trying to describe the existing v1 API as an GroupVersion("", "v1") throughout all of the code. If its hard to read like that, then there's probably a factorization problem.

@caesarxuchao @smarterclayton @liggitt @kubernetes/kube-api