Rolling operations issues

[shawkins]

The base rolling logic is applied to statefulsets, however a statefulset does not have pause attribute in its spec and is also unsupported by kubectl: https://github.com/kubernetes/kubectl/blob/652881798563c00c1895ded6ced819030bfaa4d7/pkg/polymorphichelpers/objectresumer.go

As far as I can tell the bulk of the RollingUpdater logic should not be used for deployments or statefulsets. It is only needed for replicasets and replicationcontrollers.

[shawkins]

Even after #4144 there is still an issue that rolling does not apply to all of the EditReplacePatchable operations. It only has overrides for one edit signature and patch(context, item).

@rohanKanojia @manusa Should we even be attempting a client side rolling strategy for ReplicaSets and ReplicationControllers? It is not really the same as incrementally rolling - it will bring up all pods of a new ReplicaSet before taking down the old. - I misread that. It does do them 1 at a time. Seems strange though that fabric8 has this logic and kubectl does not.

[manusa]

Should we even be attempting a client side rolling strategy for ReplicaSets and ReplicationControllers?

I need to review how we are actually achieving that. If we are covering it in a functional way, we should keep it so we don't break any current user's use-case. If we aren't and as you say neither kubectl nor client-go offer this functionality (which is indeed quite odd), we should remove it).

• https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#rolling-updates (I assume we might be doing what's explained here, and probably emulating the same behavior for ReplicaSet)

[shawkins]

If we are covering it in a functional way

We seem to be, except as it relates to patch support - the logic needs to trap the patch operation, apply it client side, then handle the rolling operation after that. This is how JSON patch is handled, but the other patch operations will proceed without triggering rolling.