-
Notifications
You must be signed in to change notification settings - Fork 150
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
Distinguish reconciliation requests triggered by the primary resource from ones triggered by others #919
Conversation
All tests passed |
All tests passed |
1 similar comment
All tests passed |
hco-e2e-image-index-gcp, hco-e2e-image-index-aws lanes succeeded. |
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-image-index-azure In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
All tests passed |
hco-e2e-upgrade-prev-aws lane succeeded. |
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-upgrade-prev-azure In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
All tests passed |
1 similar comment
All tests passed |
hco-e2e-image-index-azure, hco-e2e-image-index-aws lanes succeeded. |
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-image-index-gcp In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
All tests passed |
hco-e2e-image-index-azure, hco-e2e-image-index-gcp lanes succeeded. |
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-image-index-aws In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
All tests passed |
1 similar comment
All tests passed |
… from ones triggered by others Previous all the reconciliation resources were always enqueued using the the same HyperConverged object and this was not allowing us to distinguish reconciliation requests triggered by a change on HCO CR (the primary resource) from reconciliation requests triggered the other way around (a change on one of the CRs created and controlled by HCO). The watch on the primary resource is enqueuing with InstrumentedEnqueueRequestForObject, while the watches on secondary resources enque with EnqueueRequestsFromMapFunc so, in this second case, we can easily set there a placeholder reconcile.Request just to be able to distinguish the two flows. With this, each time we are going to reconcile a CR controlled by HCO, we can distinguish the case where we are updating it due a change started from HCO CR from the case where we are reconciling it to overwrite a change directly introduced (by the user?) on the controlled resource reverting it to an opinionated state. Let's also add an additional flag (Overwritten) to EnsureResult considering it as a subset of Updated to be able to report it back to handlers. Fixing then the log messages and adding relevant unit tests. Signed-off-by: Simone Tiraboschi <stirabos@redhat.com>
All tests passed |
All tests passed |
@tiraboschi: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
hco-e2e-upgrade-azure lane succeeded. |
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-upgrade-aws In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Ignoring slightly reduced coverage |
@tiraboschi: Overrode contexts on behalf of tiraboschi: coverage/coveralls In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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.
/approve
|
||
req := common.NewHcoRequest(hcoRequest, log, r.upgradeMode) | ||
if hcoRequest.NamespacedName != objectRequest.NamespacedName { | ||
req.Logger.Info("The reconciliation got triggered by another object") |
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.
Please add to the log - which object?
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nunnatsa 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 |
Distinguish reconciliation requests triggered by the primary resource from ones triggered by others
Previous all the reconciliation resources were always
enqueued using the the same HyperConverged object
and this was not allowing us to distinguish reconciliation
requests triggered by a change on HCO CR (the primary resource)
from reconciliation requests triggered the other way around
(a change on one of the CRs created and controlled by HCO).
The watch on the primary resource is enqueuing with
InstrumentedEnqueueRequestForObject, while the watches on secondary
resources enque with EnqueueRequestsFromMapFunc so, in this second case,
we can easily set there a placeholder reconcile.Request just to be able
to distinguish the two flows.
With this, each time we are going to reconcile a CR controlled by HCO,
we can distinguish the case where we are updating it due a change
started from HCO CR from the case where we are reconciling it to
overwrite a change directly introduced (by the user?)
on the controlled resource reverting it to an opinionated state.
Let's also add an additional flag (Overwritten) to EnsureResult considering
it as a subset of Updated to be able to report it back to handlers.
Fixing then the log messages and adding relevant unit tests.
Signed-off-by: Simone Tiraboschi stirabos@redhat.com
Release note: