Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Uniform Use of Conditions across Workloads API Surface #51594
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.
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.
I think there is a lot of value in signaling progress and failures via the API. We want to be able to inform users when they have waited long enough for an upgrade. We also want to expose failures such as when a Pod fails to be created in order to provide richer programmatic access to errors than just a "you have waited long enough". Both kinds of conditions enable higher-level orchestrators to do stuff like automatic rollbacks w/o the need to support automatic rollbacks in the API. It's not easy to do anything orchestration-wise today by using events and I don't know if that will ever be the case.
The conclusion of sig architecture is that
What we should do from here is: