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
+10-25Lines changed: 10 additions & 25 deletions
Display the source diff
Display the rich diff
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,8 @@ 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`+ positive polarity or when `Status=True` + negative polarity;
247
+
severity it is designed to provide a standard classification of possible conditions failure `Reason`.
248
248
249
249
Please note that the combination of `Reason` and `Severity` gives different meaning to a condition failure
250
250
allowing to detect when a long-running task is still ongoing:
@@ -298,6 +298,8 @@ the following constraints/design principles MUST be applied:
298
298
of the underlying `Machines.Status.Conditions[Ready]` conditions.
299
299
- A corollary of the above set of constraints is that an object SHOULD NEVER be in status `Ready=True`
300
300
if one of the object's conditions are `false` or if one of the object dependents is in status `Ready=False`.
301
+
- Condition that do not represent the operational state of the component, MUST not be included in the `Ready` condition
302
+
(e.g. `Paused`, which represent a state of the controller that manages the component).
301
303
302
304
##### Controller changes
303
305
@@ -471,6 +473,7 @@ enhance the condition utilities to handle those situations in a generalized way.
471
473
- Risk: This proposal aims to be consistent with the target state of conditions in Kubernetes, but this
472
474
is still under definition (see [KEP](https://github.com/kubernetes/enhancements/pull/1624)).
473
475
- Mitigation: Periodically re-evaluate this proposal vs the Kubernetes KEP.
476
+
- 2024-05-03: Change allowing conditions with negative polarity goes into this direction
474
477
475
478
- Risk: Cluster API presents some specific challenges that are not common to the core Kubernetes objects.
476
479
- Mitigation: To allow a minimal set of carefully evaluated differences between Cluster API and Kubernetes
@@ -480,25 +483,6 @@ enhance the condition utilities to handle those situations in a generalized way.
480
483
- Risk: This proposal allows for implementing conditions in incremental fashion, and this makes it complex
481
484
to ensure a consistent approach across all objects.
482
485
- 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
486
503
487
## Alternatives
504
488
@@ -569,5 +553,6 @@ NA
569
553
570
554
## Implementation History
571
555
572
-
- [ ] 2020-04-27: Compile a Google Doc following the CAEP template
573
-
- [ ] 2020-05-06: Create CAEP PR
556
+
- [x] 2020-04-27: Compile a Google Doc following the CAEP template
557
+
- [x] 2020-05-06: Create CAEP PR
558
+
- [x] 2024-05-03: Edited allowing conditions with negative polarity
want: FalseCondition(clusterv1.ReadyCondition, "reason falseInfo1", clusterv1.ConditionSeverityInfo, "message falseInfo1"), // bar take precedence on negativeBar because it is listed first
188
+
},
153
189
{
154
190
name: "Returns ready condition with the summary of existing conditions (using WithStepCounter options)",
options: []MergeOption{WithConditions("negative-foo"), WithNegativePolarityConditions("negative-foo", "negative-bar")}, // negative-bar should be ignored
229
+
want: TrueCondition(clusterv1.ReadyCondition),
230
+
},
231
+
{
232
+
name: "Returns ready condition with the summary of selected conditions with mixed polarity (using WithConditions options)",
233
+
from: getterWithConditions(foo, bar, negativeFoo, negativeBar),
234
+
options: []MergeOption{WithConditions("foo", "negative-foo", "negative-bar"), WithNegativePolarityConditions("negative-foo", "negative-bar")}, // bar should be ignored
0 commit comments