This makes sense to me - what's the minimal possible solution? Can you pull together a proposal?

@Kargakis
Can you clarify more what's Noop strategy? Any particular example?

@Kargakis makes sense to me. does it need to be a strategy, can't it be just an annotation to specify what manage the object? If the annotation is set, the workload controllers will ignore that objects.

@hongchaodeng for example, this will help to build "external" controllers to handle deployment process in a "custom" way.

@Kargakis makes sense to me. does it need to be a strategy, can't it be just an annotation to specify what manage the object? If the annotation is set, the workload controllers will ignore that objects.

I think the strategy type makes more sense since it's just the strategy code that we don't want to execute. We shouldn't require from authors of external controllers to implement updates to the status of the deployment or resolve overlapping selectors or do their own failure detection for core api failures since these things should be common across all types of deployments. Also the new type will be needed for DS / SS backwards-compatibilty once upgrades are supported for them.

@smarterclayton this is a simple addition in the deployment strategy types and a change in the deployment controller to ignore deployments with the new type, can't this issue serve as the proposal (not sure if I need to make a full-blown proposal for such a simple addition @bgrant0607 ?)

Opened #39352 to illustrate the changes needed for Deployments.

I'm wondering if the objective here can be factored into two parts for implementation:
(1) no-op strategy only for Deployment
(2) library for building controllers, that makes it easy for people to build new controllers by taking care of all the things you mentioned ("status updates, overlap resolution, pod creation/deletion failure detection").

Deployment is the only controller that has a "strategy" concept AFIAK.

@davidopp a library for building controllers would certainly be a nice thing, we have discussed it already with @mfojtik and we will most probably end up doing it for the Deployment controller, I am just not sure when.

Deployment is the only controller that has a strategy currently. In order to implement upgrades for DaemonSets and StatefulSets, we will end up adding a strategy field in those controllers too because 1. we need to maintain backwards compatibility (so the default strategy for them will be Noop and the additional strategy for the actual upgrade) and 2. we may end up supporting different types of strategies for DS/SS in the future apart from the initial one.

I think there's a reasonable philosophical question of when the pattern you're using here (delegate some behavior of a controller to specialized external logic) is appropriate vs. telling people to write their own controller that contains the specialized logic plus the base logic of the controller. My suggestion about a library was trying to get at how to do this without a lot of code duplication. But probably this would be a bad use experience since it would lead to a proliferation of very similar controllers.

So never mind my comment.

If I understand correctly, this proposal is talking about top-level objects that simply update status and cannot directly control the underlying pods. So far, there was some discussion on implementing this sort of functionality in TPRs. For example, there is already a need to implement status reporting in TPRs such that kubernetes can interpret and monitor these resources, so as to gain visibility into externally managed pod-creating abstractions.

If I understand correctly, this proposal is talking about top-level objects that simply update status and cannot directly control the underlying pods. So far, there was some discussion on implementing this sort of functionality in TPRs. For example, there is already a need to implement status reporting in TPRs such that kubernetes can interpret and monitor these resources, so as to gain visibility into externally managed pod-creating abstractions.

I love the idea of TPR in general but I am not convinced about structuring it to fit the needs of a workload controller api-wise and I don't believe it will prevail our core controllers for running workloads in the future although I believe operators will be used for running many things. One thing worth considering is how easy it can be for a user to run custom logic by using TPRs vs an external Deployment. I still haven't got to build anything with TPRs yet but I would expect that I need to 1. know Go, 2. be familiar with the Kubernetes APIs, whereas I can provide a simple bash script with kubectl commands, feed it to a controller framework, and be done with it.

I would expect that I need to 1. know Go, 2. be familiar with the Kubernetes APIs, whereas I can provide a simple bash script with kubectl commands, feed it to a controller framework, and be done with it.

The plan with TPRs is to allow kubectl to interact with them approximately the same way as any first class kubernetes object, letting TPRs "implement" common patterns like scale and status. I think it wouldn't be a big leap to allow a TPR to implement a 'workload controller' pattern that lets a given object watch and report changes to pods that it manages. Even if we don't use TPRs for this, it seems like it should be a completely separate entity from existing workload controllers for the following reasons:

• The type of "status" that we get from deployments may not be sufficient for all applications, especially as we build higher level objects. For example, in case of a SparkJob, it contains several "types" of pods which it manages, drivers and executors and aggregating them into one single notion of "available/desired pods" when reporting status does not make much sense.
• Traditional and external deployments under this model would be fundamentally different in nature: we're overloading the update strategy to change the basic behavior (orchestration), at that point, I think we might as well make a separate ExternalController type.
• The same no-op strategy in other controllers (StatefulSet for example), wouldn't provide anything over that in Deployments as far as I can tell, unless I misunderstand the proposal somehow.

Related issue: #31571

I believe this to be a dupe, or special case, of #31571.

Let's keep the TPR-related discussion in #38113.

#31571 is more of an umbrella issue. Closing as a dupe of #14510