Update the ConditionSet to support non-terminal conditions. #161
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
There was a problem hiding this comment.
@mattmoor: 0 warnings.
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.
n3wscott
approved these changes
Nov 2, 2018
| } | ||
|
|
||
| // 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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 2, 2018
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.
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 3, 2018
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 3, 2018
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.
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 3, 2018
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 |
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 8, 2018
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.
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 8, 2018
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 8, 2018
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.
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 8, 2018
knative-prow-robot
pushed a commit
to knative/serving
that referenced
this pull request
Nov 8, 2018
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.
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 8, 2018
|
/hold cancel |
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 9, 2018
mattmoor
added a commit
to mattmoor/serving
that referenced
this pull request
Nov 9, 2018
knative-prow-robot
pushed a commit
to knative/serving
that referenced
this pull request
Nov 9, 2018
chengjingtao
pushed a commit
to katanomi/knative-pkg
that referenced
this pull request
Oct 22, 2024
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.