New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle alternate forms of resource status #233
Conversation
We previously assumed that a resource either conformed to our notion of status or didn't have a status field at all. If a status field existed, but either didn't have the structure we expected or did have the structure but was a pointer, would err. Now we gracefully unpack the status as best we can, and safely ignore cases where the structure does not conform to our ideal structure. In those cases the functionality that would be applied is skipped. This includes: - calling `status.InitializeConditions()` - setting `status.ObservedGeneration` - normalizing the LastTransitionTime for conditions Signed-off-by: Scott Andrews <andrewssc@vmware.com>
Signed-off-by: Scott Andrews <andrewssc@vmware.com>
Codecov Report
@@ Coverage Diff @@
## main #233 +/- ##
==========================================
+ Coverage 65.41% 65.83% +0.42%
==========================================
Files 9 9
Lines 1067 1127 +60
==========================================
+ Hits 698 742 +44
- Misses 348 360 +12
- Partials 21 25 +4
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[thought, non-blocking]: I am wondering if the best-effort initialization of conditions could benefit from logs. It may easily get noisy though. I will be able to observe if rr
initializes my resource's conditions, but if it doesn't logs may help.
[issue/thought, non-blocking]: As far as I can tell, MyResourceStatus.InitializeConditions()
is an undocumented convention. I discovered it by reading other project's code. Maybe we could elevate it to a more prominent feature of the API through an interface or another mechanism.
LGTM 👍🏻
We log when a ParentReconciler is setup when: - there is no status - the status is a pointer - the status doesn't have a ObservedGeneration int64 field - the status doesn't have a Conditions []metav1.Condition field - the status doesn't have an InitializeConditions() method None of these will block the system at runtime, if a field/method is missing, the behavior is skipped. Signed-off-by: Scott Andrews <andrewssc@vmware.com>
Signed-off-by: Scott Andrews <andrewssc@vmware.com>
We previously assumed that a resource either conformed to our notion of
status or didn't have a status field at all. If a status field existed,
but either didn't have the structure we expected or did have the
structure but was a pointer, would err.
Now we gracefully unpack the status as best we can, and safely ignore
cases where the structure does not conform to our ideal structure. In
those cases the functionality that would be applied is skipped. This
includes:
status.InitializeConditions()
status.ObservedGeneration
Resolves #186 #108