Do we need something like update strategy?

Shouldn't that be similar to what deployments currently provide?

We are going to add a struct as per @smarterclayton's suggestion

We should also add a rollback spec and a rollback subresource, otherwise every client needs to implement its own logic for rollback.

@kow3ns what is the conclusion here ? I am guessing we all are in agreement , that we need a struct for strategy and rollbackConfig

For rollback, if we are worried about spec mutation (the controller cleans up the rollback spec once it successfully rollbacks a controllee), could we still have a server-side implementation w/o using a struct in the spec (the rollback is performed by the api server and not the controller)?

typo

Which component is going to increase this field?

API Server

Why isn't this a generation?

Will update for consistency with DaemonSet.

Is this a final decision? In DaemonSets we didn't decided yet how to store a history. cc @Kargakis @janetkuo @smarterclayton

Yeah, we haven't yet. I think we need to get a quick list of options written up and discussed:

1. PodTemplate (collision between use for different controller types)
2. Specific type for each controller: DaemonSetHistory, StatefulSetHistory, etc (no reuse between controllers)
3. Storing a limited subset of specs on the object (size limits)
4. ???

I'm obviously partial to 1. My primary reason is that controllers should not be special and require magic. If we get TPRs right then PodTemplates can be leveraged by arbitrary operators/controllers, and they, therefore, provide a primitive upon which others can build.

So for pod template here's what we need to handle:

1. Collisions across controllers by naming
2. Idempotency of product versions (the same pod template in a controller object should map to exactly one PodTemplate across multiple upgrades)
3. Human readability - a human should be able to find a PodTemplate
4. Collisions across controllers by pod template spec - if two controllers deploy the exact same pod template (daemon set vs stateful set) the PodTemplate has two owners, not just one, so garbage collection won't work
5. Future versions of controllers may involve renames of the controller resource name, so we would still have to be able to locate old PodTemplate revisions even if the resource name changes
6. Immutability of PodTemplate - a template used in this fashion needs to prevent updates, or at least strongly discourage them (if they are mutable, we can't compare the pods against the pod template version).

I think the real issue is 1 - the rest of the problems apply to ReplicaSets owned by Deployments too.

For clarity, I am talking about the UID of the parent.

@smarterclayton @janetkuo @Kargakis @lukaszo

Before we go forward with PodTemplate creation we should also discuss adding a History sub resource to the controllers (I believe that is something like option 3 above).

Having a per Kind History sub resource mitigates History overlap across Kinds with the same .Name in the same namespace. My argument about PodTemplate being a primitive that is usable without controller specific magic is valid (imo), but perhaps its also a straw man.

Right now the category of controllers could loosely be defined like this.
A generative controller takes, as an argument, an Object that represents the declared target state. The Object must have the following properties

1. A .Spec.Template that is a template for Objects of the generated Kind.
2. A .Spec.Replicas that expresses the desired cardinality of the generated Kind.
3. A Generation that indicates the version of the declared target state.
4. A .Status.Replicas that indicates the number of created replicas.
5. If the Objects of created Kind are not immediately available upon creation, a .Status.ReadyReplicas to indicate the number of available created resources.
   1. A .Satus.ObservedGeneration that indicates the version of the target state specification that the controller has observed.

I confirmed with @foxish that the plan to support third party controller and operators is to make these properties well supported. That is, we want them to create custom Kinds that contain these sub resources. Given that, adding a History sub resource might be the best fit.

We could say that controllers that implement revision history must have

1. A History.Revision where the type of this object is an []PodTemplate or []PodTemplateSpec.
2. A History.RevisionLimit that indicates the number of stored revisions.
3. A Spec.TemplateGeneration that is incremented by the API server upon mutation of the .Spec.Template.

There has been some discussion before and I think there is general agreement that we want a history subresource. I am not sure whether we need to have this discussion in this proposal or in a separate one since it 1. affects all of the workload controllers and 2. is not required for having StatefulSet upgrades.

I don't have a problem with putting uids in names of generated resources provided they are ONLY used for uniquification and NEVER used for discovery/searching.

Prevention of mutation and deletion is also desired in other contexts (e.g., addons): kubernetes/kubernetes#10179