FEATURE REQUEST:

tldr: We should either remove Conditions from the workloads API surface or invest in them.

The workloads API does not use Conditions uniformly across the surface.

If they are valuable to users, and if their current use is a best practice, we should use them uniformly across the API surface. If they are not valuable, or if we should really be using Status fields for the workloads API, we should deprecate them (preferably prior to v1).

To achieve consistency across the surface we could take three approaches.

1. Invest in Conditions - If they have value we should use them more uniformly.

   1. StatefulSet could add a Condition type to indicate InProgress when it has less than the desired number of replicas, Available when all Pods are Ready, and Blocked when it fails to launch a Pod and it can no longer make progress due to its ordering constraint.
   2. DaemonSet could add a Condition type to indicate InProgress when it has yet to launch a Pod on all Nodes that its Node selector matches, Failed when it can't schedule a Pod on a Node due to a resource constraint violation (port conflict, insufficient non-compressible resource, etc), and Saturated when all selected Nodes have a Pod that is Ready.

2. Move Conditions to Fields - Aside from reason and message, the information contained in Deployment and ReplicaSet Conditions can be represented as an enumeration (this will have the same issue as Phase) and a boolean value respectively. We will no longer have the ability communicate messages and reasons via Status, but we could consider providing these asynchronously via Events.

3. Remove Conditions - If we think (2) is a good idea, we should also consider removing Conditions entirely. Without a reason or a message, the condition field is a summary that is mostly extrapolated form other fields of the objects' Status.

The investment to maintain what is implemented for (1) is non-trivial, and the investment to ship it as a feature that spans the workloads API surface is significant when we account for maintenance cost throughout the lifetime of the API. The detailed data collected in #50798 seems to demonstrate the use of Conditions is far from Universal in our API objects and that most of the fields of Conditions, when implemented, are not used.

(2) and (3) have a one time cost to modify the Deployment and ReplicaSet APIs, and they reduce maintenance overhead across the workloads API, but if we want to converge the storage and processing for ReplicaSet and ReplicationController we will have to carry the deprecation for quite a long time. Also, we should consider that, though they are few, the uses of Deployment Conditions might add legitimate value and warrant adoption in other controllers.

API
@kubernetes/sig-api-machinery-feature-requests
Given #7856 and community #606 we still lack a formal direction on when to use Status fields vs Conditions in the general case. We do seem to agree that we should not use them to build state machines and that they should be orthogonal to Phase. Given the options above, or any others that we should consider, what is consistent with best practices for the k8s API surface?

Apps
@kubernetes/sig-apps-feature-requests
Are Deployment Conditions useful? Is the work required to ship and maintain (1) worth it, or are (2) or (3) sufficient?