* 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
* #457 Duck type user annotation logic
* #457 Duck type user annotation logic - tests
* #457 Revert updater annotation key from lastModifier to updater
* #457 Rename HasSpec#GetSpec() to HasSpec#GetUntypedSpec()
* #457 Fix some indentation
* #457 Get group for user info annotations from the request
* #457 Reduce confusuion in webhook testing by using same group
* Add support for a structured URL type.
This type can be used to accept `url: http://asdf.com` where in code we
get a `url.URL` to interact with.
* Propagate errors parsing, cast pointer instead of copying.
* have simple tests. working on impl.
* strict setting, reflection based.
* ran codegen.
* adding license.
* update based on feedback and merge better.
* getting closer to something simpler assuming shallow reflect.
* adding validation test.
* use the json tag.
* Golang things nil typed pointers are not nil.
* Use real value of reflect invalid.
* add a missing test.
* two methods, one for update, one for single check.
* checkdep is now in apis.
* fix pkg.
* Update apis/deprecated_test.go
Co-Authored-By: n3wscott <32305648+n3wscott@users.noreply.github.com>
* add code clarity.
* include inlined struct objects recursively.
* Update commnets and add a flatten error test for inlined.
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).
This deprecates the `apis.Immutable` and `apis.Annotatable` interfaces,
which were both awkward niche extensions of `apis.Validatable` and
`apis.SetDefaults` for specific contexts that the former set didn't
cover well.
With this change, the expectation is that types that want to check
for immutability will instead access the "baseline" object via the
context from within updates. For example:
```
func (new *Type) Validate(ctx context.Context) *apis.FieldError {
if apis.IsInUpdate(ctx) {
old := apis.GetBaseline(ctx).(*Type)
// Update specific validation based on new and old.
}
}
```
For applying user annotations, the type writer can write:
```
func (new *Type) SetDefaults(ctx context.Context) {
if apis.IsInCreate(ctx) {
ui := apis.GetUserInfo(ctx)
// Set creator annotation from ui
}
if apis.IsInUpdate(ctx) {
ui := apis.GetUserInfo(ctx)
old := apis.GetBaseline(ctx).(*Type)
// Compare old.Spec vs. new.Spec and on changes
// update the "updater" annotation from ui.
}
}
```
One of the key motivations for this refactoring was to enable us
to do more powerful validation in `apis.Validate` beyond the niche
of immutability checking (and without introducing yet-another
one-off niche interface). In the BYO Revision name PoC I abused
`apis.Immutable` to do more arbitrary before/after validation,
which with this can simply be a part of `apis.Validatable`.
See: https://github.com/knative/serving/pull/3562
The general stance on deprecating interfaces such as these will be
to deprecate them in a non-breaking way (via a comment for now). They
will be hollowed out when the functionality is removed from the webhook,
but left in because of diamond dependency problems. In this change
we remove the `apis.Annotatable` functionality and deprecate the
`apis.Immutable` functionality.
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
With this, the expectation is that folks can embed the following in
the status of their resource:
```go
type FooStatus struct {
duckv1alpha1.Status `json:",inline"`
// other fields
}
```
`ObservedGeneration` is important to the usefulness of our standard
conditions because `{Ready,Succeeded}: True` is only meaningful when
`.status.observedGeneration == .metadata.generation`.
When `.status.observedGeneration != .metadata.generation` it indicates
that the controller has not yet attempted to reconcile a change in the
desired state of the world (aka `spec:`).
Laszlo Bence Nagy