Update the ConditionSet to support non-terminal conditions.#161
Update the ConditionSet to support non-terminal conditions.#161knative-prow-robot merged 2 commits intoknative:masterfrom
Conversation
This change updates the `ConditionSet` datatype to treat the set of conditions that it is initially supplied with as the set of "terminal" conditions, where as before: 1. If all `True`, results in `Ready=True` 2. If any `False`, results in `Ready=False` 3. Otherwise, `Ready=Unknown` However, in additional to this initial "terminal" set, other conditions may be set that are "non-terminal" and have no influence over the "happy" condition (e.g. `Ready`). Related to: knative/serving#2394
knative-prow-robot
left a comment
There was a problem hiding this comment.
@mattmoor: 0 warnings.
Details
In response to this:
This change updates the
ConditionSetdatatype to treat the set of conditions that it is initially supplied with as the set of "terminal" conditions, where as before:
- If all
True, results inReady=True- If any
False, results inReady=False- Otherwise,
Ready=UnknownHowever, in additional to this initial "terminal" set, other conditions may be set that are "non-terminal" and have no influence over the "happy" condition (e.g.
Ready).Related to: knative/serving#2394
I'm putting a
/holdon this until we discuss at next week's API WG.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
| } | ||
|
|
||
| // set the happy condition | ||
| r.SetCondition(Condition{ |
| types := []ConditionType{t} | ||
| for _, cond := range r.dependents { | ||
| if cond == t { | ||
| types = append(types, r.happy) |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mattmoor, n3wscott The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
To allow treating `BuildSucceeded` as a terminal condition when we adjust the model as outlined in knative/pkg#161, we need to pass it to the `ConditionSet` constructor. This flushes out the downstream changes of that.
To allow treating `BuildSucceeded` as a terminal condition when we adjust the model as outlined in knative/pkg#161, we need to pass it to the `ConditionSet` constructor. This flushes out the downstream changes of that.
This adds a Severity field to our common Condition type, as outlined [here](knative/serving#2394 (comment)). The only way Severity is populated in this change is: * Terminal conditions (passed at initial construction) always result in `severity: Error`, * non-Terminal conditions (added outside initial set) always result in `severity: Info`. We should think about how we want to update the `Condition{Set,Manager}` interfaces to surface more control (e.g. `severity: Warning`).
|
I've updated this with /hold I am putting a hold on this because I'd like to coordinate this going in with an update to |
|
/lgtm |
To allow treating `BuildSucceeded` as a terminal condition when we adjust the model as outlined in knative/pkg#161, we need to pass it to the `ConditionSet` constructor. This flushes out the downstream changes of that.
To allow treating `BuildSucceeded` as a terminal condition when we adjust the model as outlined in knative/pkg#161, we need to pass it to the `ConditionSet` constructor. This flushes out the downstream changes of that.
To allow treating `BuildSucceeded` as a terminal condition when we adjust the model as outlined in knative/pkg#161, we need to pass it to the `ConditionSet` constructor. This flushes out the downstream changes of that.
|
/hold cancel |
knative#161) * feat:add function to list commit and add additional information to commit * feat:set status for list commitstatus when one commit failed (knative#168) * add debug log * feat: Add pagging metadata to ListMeta * feat: Adds convert http response error into kubernetes error * fix: boilerplate on new file Co-authored-by: jjzhang <jjzhang@alauda.io> Co-authored-by: Daniel <danielfbm@gmail.com>
This change updates the
ConditionSetdatatype to treat the set of conditions that it is initially supplied with as the set of "terminal" conditions, where as before:True, results inReady=TrueFalse, results inReady=FalseReady=UnknownHowever, in additional to this initial "terminal" set, other conditions may be set that are "non-terminal" and have no influence over the "happy" condition (e.g.
Ready).Related to: knative/serving#2394
I'm putting a
/holdon this until we discuss at next week's API WG.