Commit Graph

11 Commits

Author SHA1 Message Date
Dave Protasowski 8535fcc248
gofumpt the repo (#3067)
* gofumpt the repo

* don't prefix numbers with 0 - otherwise they're octal
2024-06-25 07:27:07 +00:00
Victor Agababov a371418524
v2 (#1754) 2020-09-29 13:18:29 -07:00
Markus Thömmes d29cf98a77
Assorted linting fixes. (#1249)
* Remove unused code.

* Use raw strings to avoid escaping.

* Remove unneeded type conversions.

* Preallocate slices where possible.

* Use semantic equality in psbinding reconciler.
2020-04-28 08:20:51 -07:00
Kenjiro Nakayama fcff978f32
Do not set to unknown status when all dependents passed happy check (#1187)
* Do not set to unknown status when all dependents passed unhappy check

`accessor.GetConditions()` in `findUnhappyDependent()` gets status
filed from runtime. So, if an object has following status:

```
  status:
    address:
      url: http://hello-example.default.svc.cluster.local
    conditions:
    - lastTransitionTime: "2020-04-02T09:49:03Z"
      status: "True"
      type: AllTrafficAssigned
    - lastTransitionTime: "2020-04-02T09:49:03Z"
      message: autoTLS is not enabled
      reason: AutoTLSNotEnabled
      severity: Info
      status: "True"
      type: CertificateProvisioned
    - lastTransitionTime: "2020-04-02T09:49:05Z"
      status: "True"
      type: IngressReady
    - lastTransitionTime: "2020-04-02T09:49:05Z"
      status: "True"
      type: Ready
```

`accessor.GetConditions()` returns AllTrafficAssigned,
CertificateProvisioned, IngressReady (and Ready).

Then, current code (`len(r.dependents) != len(conditions)`) sets to
Unknown if all conditions are not unhappy. However, it does not work
if we added a new dependent and downgraded the cluster because
the number of dependents is less than current status conditions.

If all dependents are verified, it should not set to unknown
status. So, this patch changed it.

* Add unit test
2020-04-04 11:10:18 -07:00
Kenjiro Nakayama c13e86e2d4
Add MarkTrueWithReason function to ConditionManager (#1148)
* Add MarkTrueWithReason function to ConditionManager

When using `MarkTrue()` function, it does not allow us to add the reason and message.
Also, if we use `SetCondition()` instead, it does not update the happy condtion.

So, this PR adds new `MarkTrueWithReason(reason, message)` function.

* Make test better

* Add unit test for MarkTrueWithReason

* Rename markHappy with recomputeHappiness
2020-03-19 09:36:06 -07:00
Scott Nichols d9a38f13e8
Nil check conditions (#1112)
* Realized a corner case on ordering and False > Unknown states.

* add test with unknown fall through.

* I guess some integartions allow nil happy

* add unit tests for GetMessage and GetReason

* all conditons can be nil.

* Search for unhappy dependents.

* update codegen

* Remove KResource from v1alpha1 ducks.
2020-02-20 11:20:06 -08:00
Scott Nichols d38e1f8bde
Realized a corner case on ordering and False > Unknown states. (#1110)
* Realized a corner case on ordering and False > Unknown states.

* add test with unknown fall through.
2020-02-20 06:55:06 -08:00
Scott Nichols 5c9bc970ce
Clear falied propagation status of the top level condition if cleared. (#1108) 2020-02-19 21:16:06 -08: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
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