-
Notifications
You must be signed in to change notification settings - Fork 19
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
Enable status reporting for CatalogSource in OperatorPolicy #195
Enable status reporting for CatalogSource in OperatorPolicy #195
Conversation
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.
You've got the right idea overall!
fb72348
to
c5215ec
Compare
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.
I think an additional test scenario for a situation where the catalogsource is present, but not healthy, would cover the functionality I think this is still missing. To trigger that, I think you could patch the catalogsource's image. You might need to delete the existing catalogsource pod, I'm not sure how exactly it handles when that is updated, or how quickly the new status will be reflected.
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.
This mostly looks good! There are a few places where I'm worried there was a merge conflict that didn't quite get resolved correctly. Let me know if you need help looking at that.
The first test run had a failure on an unrelated test. I'm re-running the test. |
aac5d37
to
5c86cfe
Compare
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.
Thanks for addressing all of the comments, I think this is functionally ready to go! I noticed two small things in the test now that the GitHub diff was more readable, and I think after that it will be ready to merge.
Following the schema of implementing multiple `handle` functions, the CatalogSource status reporting logic utilizes the same `updateStatus` function to facilitate the `conditions` and `relatedObject` field updates on the related operator policy. The controller directly checks if the CatalogSource object exists on the cluster to propagate relevant health information up to the operator policy. The specific field that is checked in the catalog source is `.status.connectionState.lastObservedState`. Any value other than `READY` is considered as failing. ref: https://issues.redhat.com/browse/ACM-9285 Signed-off-by: Jason Zhang <jaszhang@redhat.com>
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.
Thanks, LGTM!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JustinKuli, zyjjay 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 |
8f18c31
into
open-cluster-management-io:main
Following the schema of implementing multiple
handle
functions, the CatalogSource status reporting logic utilizes the sameupdateStatus
function to facilitate theconditions
andrelatedObject
field updates on the related OperatorPolicy. The controller reads the conditions field on the watched Subscription to determine the health of the CatalogSource. In the event a Subscription is not created due to either aninform
OperatorPolicy or an error, the controller directly checks if the CatalogSource object exists on the cluster to propagate relevant health information up to the OperatorPolicy.ref: https://issues.redhat.com/browse/ACM-9285