-
Notifications
You must be signed in to change notification settings - Fork 544
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
Fix RichReference Ordering #2880
Fix RichReference Ordering #2880
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: awgreene 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 |
Fixes #2874 |
vendor/github.com/operator-framework/api/pkg/operators/v1/operator_types.go
Outdated
Show resolved
Hide resolved
3b10544
to
4043df9
Compare
87e311e
to
e694a2b
Compare
I'll have to bump the k8s version to v0.25.0 to use the changes introduced in operator-framework/api#271 |
f45bab5
to
4eddd8c
Compare
4eddd8c
to
6bbcd09
Compare
b0a6ee7
to
508d4d2
Compare
/lgtm |
/retest |
508d4d2
to
622df64
Compare
New changes are detected. LGTM label has been removed. |
LGTM once #2880 (comment) is resolved and tests are green. Just want to make sure we're not introducing a debug artifact into the reconciliation logic, and I think we could get the current status view from inspecting the actual object itself. |
622df64
to
73bd7c9
Compare
Problem: The operator CR's status includes a list of componenets owned by the operator. The list of components are ordered by GVK, but the order of objects with the same GVK may change. If an operator owns many components, there is a high likelyhood that OLM will continuously update the status of the operator CR because the order of its components have changed, Solution: Order an operators component references so OLM does not attempt to update the status of the operator CR. Signed-off-by: Alexander Greene <greene.al1991@gmail.com>
73bd7c9
to
ec1e04b
Compare
Thanks for the review @timflannagan, we should be good to go! |
/lgtm |
1 similar comment
/lgtm |
Problem: The operator CR's status includes a list of componenets owned by the operator. The list of components are ordered by GVK, but the order of objects with the same GVK may change. If an operator owns many components, there is a high likelyhood that OLM will continuously update the status of the operator CR because the order of its components have changed
Solution: Order an operators component references so OLM does not attempt to update the status of the operator CR.
Signed-off-by: Alexander Greene greene.al1991@gmail.com