Commit Graph

6 Commits

Author SHA1 Message Date
capri-xiyue fa1c639c93 Add helper methods in conditon_set (#965)
* added isUnknown in condition_set

* added IsFalse for condition set

* added GetHappyCondition

* modified comments

* modified the code based on cr

* renamed the method and removed isXXX() methods

* modified comments
2020-01-06 08:00:49 -08:00
Andrew Poydence 972acd413f apis: fix typo in ConditionSet.Manage comment (#551) 2019-07-30 08:52:43 -07:00
Johnu George 86f49e59e0 Implement ClearCondition for ConditionManager (#538)
* Implement RemoveCondition for ConditionManager

This implements RemoveCondition to remove a condition that matches
the condition type. Happy condition is changed appropriately if it
is a terminal and satifies one of the following conditions
1. RemovedCondition is false and happy is false
    Happy can change from false to unknown or true
2. RemovedCondition is unknown and happy is unknown
    Happy can change from unknown to true

* comment edit

* Addresses review comments

* Support only non terminal conditions

* Fix check
2019-07-24 14:22:35 -07:00
Victor Agababov 74c5d67ea0 Fix the issues pointed out by staticcheck (#541)
* Fix the issues pointed out by staticcheck

* review fix
2019-07-23 13:13:36 -07:00
Matt Moore 31649c272a Start to lay the groundwork for Status conversion. (#373)
The backbone of our Condition system is our "happy" condition and
the semantics governing how other subconditions influence that condition.
When looking towards Conversion, it is possible for the set of conditions
to vary between `v1alpha1` and `v1beta1`, but the "happy" condition should
remain consistent across versions.

The main changes:
1. Provide a `ConvertTo` helper for "converting" between `duckv1beta1.Status`
 types in this "lowest common denominator" sense, where we just copy the
 happy condition.
2. When `InitializeConditions()` (plural) is called, seed the initial state
 of sub-conditions from the initial state of the "happy" condition, if True.

This change enables us to completely change the condition space across
versions, while maintaining the consistency of the happy condition.

A couple peripheral changes:
1. Add `context.Context` to the `apis.Convertible` interface.
2. Drop `InitializeCondition()` (singular) from the `ConditionsManager` interface (I don't see any usage outside of this file).
2019-04-09 08:22:59 -07:00
Matt Moore 281cda84ce Move Condition stuff to apis, add a v1beta1 Status. (#361)
This moves the common Condition stuff to apis, and creates a v1beta1 form of Status that uses the Condition it defines (changing this in v1alpha1 is too breaking).

There aren't really any meaningful changes in this PR, mostly reorganization.  Enumerating what I did:
1. Copied `condition_set*.go` to `apis/`,
1. Copied the `Condition` portions of `conditions_types.go` to `apis/`,
1. Copied the balance of `conditions_types.go` to `apis/duck/v1beta1/status_types.go`,
1. Changed the parts of the above to reference things in the appropriate new places,
1. Removed the reflection-based `ConditionsAccessor` stuff, implementing it instead on `duckv1beta1.Status`.
1. Incorporate: https://github.com/knative/pkg/pull/358
2019-04-02 09:51:55 -07:00