You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/proposals/20200506-conditions.md
+11-25
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ reviewers:
6
6
- "@vincepri"
7
7
- "@ncdc"
8
8
creation-date: 2020-05-06
9
-
last-updated: 2020-05-20
9
+
last-updated: 2024-05-03
10
10
status: implementable
11
11
see-also:
12
12
replaces:
@@ -232,7 +232,7 @@ const (
232
232
)
233
233
```
234
234
235
-
Condition types MUST have a consistent polarity(i.e. "True = good");
235
+
Condition type names should make sense for humans; neither positive nor negative polarity can be recommended as a general rule.
236
236
237
237
Condition types SHOULD have one of the following suffix:
238
238
@@ -243,8 +243,9 @@ When the above suffix are not adequate for a specific condition type, other suff
243
243
(e.g. `Completed`, `Healthy`); however, it is recommended to balance this flexibility with the objective to provide
244
244
a consistent condition naming across all the ClusterAPI objects.
245
245
246
-
The `Severity` field MUST be set only when `Status=False` and it is designed to provide a standard classification
247
-
of possible conditions failure `Reason`.
246
+
The `Severity` field MUST be set only when `Status=False`for conditions with positive polarity, or when `Status=True`
247
+
for conditions with negative polarity; severity is designed to provide a standard classification of possible
248
+
conditions failure `Reason`.
248
249
249
250
Please note that the combination of `Reason` and `Severity` gives different meaning to a condition failure
250
251
allowing to detect when a long-running task is still ongoing:
@@ -298,6 +299,8 @@ the following constraints/design principles MUST be applied:
298
299
of the underlying `Machines.Status.Conditions[Ready]` conditions.
299
300
- A corollary of the above set of constraints is that an object SHOULD NEVER be in status `Ready=True`
300
301
if one of the object's conditions are `false` or if one of the object dependents is in status `Ready=False`.
302
+
- Condition that do not represent the operational state of the component, MUST not be included in the `Ready` condition
303
+
(e.g. `Paused`, which represent a state of the controller that manages the component).
301
304
302
305
##### Controller changes
303
306
@@ -471,6 +474,7 @@ enhance the condition utilities to handle those situations in a generalized way.
471
474
- Risk: This proposal aims to be consistent with the target state of conditions in Kubernetes, but this
472
475
is still under definition (see [KEP](https://github.com/kubernetes/enhancements/pull/1624)).
473
476
- Mitigation: Periodically re-evaluate this proposal vs the Kubernetes KEP.
477
+
- 2024-05-03: Change to allow conditions without positive polarity goes into this direction
474
478
475
479
- Risk: Cluster API presents some specific challenges that are not common to the core Kubernetes objects.
476
480
- Mitigation: To allow a minimal set of carefully evaluated differences between Cluster API and Kubernetes
@@ -480,25 +484,6 @@ enhance the condition utilities to handle those situations in a generalized way.
480
484
- Risk: This proposal allows for implementing conditions in incremental fashion, and this makes it complex
481
485
to ensure a consistent approach across all objects.
482
486
- Mitigation: Ensure all the implementations comply with the defined set of constraints/design principles.
483
-
484
-
- Risk: Having a consistent polarity ensures a simple and clear contract with the consumers, and it allows
485
-
processing conditions in a simple and consistent way without being forced to implement specific logic
486
-
for each condition type. However, we are aware about the fact that enforcing of consistent polarity (truthy)
487
-
combined with the usage of recommended suffix for condition types can lead to verbal contortions to express
488
-
conditions, especially in case of conditions designed to signal problems or in case of conditions
489
-
that might exist or not.
490
-
- Mitigation: We are relaxing the rule about recommended suffix and allowing usage of custom suffix.
491
-
- Mitigation: We are recommending the condition adhere to the design principle to express the operational state
492
-
of the component, and this should help in avoiding conditions name to surface internal implementation details.
493
-
- Mitigation: We should recommend condition implementers to clearly document the meaning of Unknown state, because as
494
-
discussed also in the recent [Kubernetes KEP about standardizing conditions](https://github.com/kubernetes/enhancements/pull/1624#pullrequestreview-388777427),
495
-
_"Unknown" is a fact about the writer of the condition, and not a claim about the object_.
496
-
- Mitigation: We should recommend developers of code relying on conditions to treat Unknown as a separated state vs
497
-
assimilating it to True or False, because this can vary case by case and generate confusion in readers.
498
-
499
-
As a final consideration about the risk related to using a consistent polarity, it is important to notice that a
500
-
consistent polarity ensure a clear meaning for True or o False states, which is already an improvement vs having
501
-
different interpretations for all the three possible condition states.
502
487
503
488
## Alternatives
504
489
@@ -569,5 +554,6 @@ NA
569
554
570
555
## Implementation History
571
556
572
-
- [ ] 2020-04-27: Compile a Google Doc following the CAEP template
573
-
- [ ] 2020-05-06: Create CAEP PR
557
+
- [x] 2020-04-27: Compile a Google Doc following the CAEP template
558
+
- [x] 2020-05-06: Create CAEP PR
559
+
- [x] 2024-05-03: Edited allowing conditions with negative polarity
want: FalseCondition(clusterv1.ReadyCondition, "reason falseInfo1", clusterv1.ConditionSeverityInfo, "message falseInfo1"), // bar take precedence on barWithNegativePolarity because it is listed first
187
+
},
153
188
{
154
189
name: "Returns ready condition with the summary of existing conditions (using WithStepCounter options)",
options: []MergeOption{WithConditions("foo-negative-polarity"), WithNegativePolarityConditions("foo-negative-polarity", "bar-negative-polarity")}, // bar-negative-polarity should be ignored because it is not listed in WithConditions
228
+
want: TrueCondition(clusterv1.ReadyCondition),
229
+
},
230
+
{
231
+
name: "Returns ready condition with the summary of selected conditions with mixed polarity (using WithConditions options)",
232
+
from: getterWithConditions(foo, bar, fooWithNegativePolarity, barWithNegativePolarity),
0 commit comments