Skip to content
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

Merged
merged 1 commit into from
Nov 8, 2020

Conversation

tiraboschi
Copy link
Member

@tiraboschi tiraboschi commented Nov 5, 2020

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:

Distinguish reconciliation requests triggered by the primary resource from ones triggered by others

@kubevirt-bot kubevirt-bot added release-note-none Denotes a PR that doesn't merit a release note. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. labels Nov 5, 2020
@ovirt-infra
Copy link

All tests passed

@kubevirt-bot kubevirt-bot added size/M and removed size/S labels Nov 5, 2020
@ovirt-infra
Copy link

All tests passed

1 similar comment
@ovirt-infra
Copy link

All tests passed

@hco-bot
Copy link
Collaborator

hco-bot commented Nov 5, 2020

hco-e2e-image-index-gcp, hco-e2e-image-index-aws lanes succeeded.
/override ci/prow/hco-e2e-image-index-azure

@kubevirt-bot
Copy link
Contributor

@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-image-index-azure

In response to this:

hco-e2e-image-index-gcp, hco-e2e-image-index-aws lanes succeeded.
/override ci/prow/hco-e2e-image-index-azure

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.

@ovirt-infra
Copy link

All tests passed

@hco-bot
Copy link
Collaborator

hco-bot commented Nov 5, 2020

hco-e2e-upgrade-prev-aws lane succeeded.
/override ci/prow/hco-e2e-upgrade-prev-azure

@kubevirt-bot
Copy link
Contributor

@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-upgrade-prev-azure

In response to this:

hco-e2e-upgrade-prev-aws lane succeeded.
/override ci/prow/hco-e2e-upgrade-prev-azure

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.

@ovirt-infra
Copy link

All tests passed

1 similar comment
@ovirt-infra
Copy link

All tests passed

@hco-bot
Copy link
Collaborator

hco-bot commented Nov 5, 2020

hco-e2e-image-index-azure, hco-e2e-image-index-aws lanes succeeded.
/override ci/prow/hco-e2e-image-index-gcp

@kubevirt-bot
Copy link
Contributor

@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-image-index-gcp

In response to this:

hco-e2e-image-index-azure, hco-e2e-image-index-aws lanes succeeded.
/override ci/prow/hco-e2e-image-index-gcp

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.

@ovirt-infra
Copy link

All tests passed

@hco-bot
Copy link
Collaborator

hco-bot commented Nov 6, 2020

hco-e2e-image-index-azure, hco-e2e-image-index-gcp lanes succeeded.
/override ci/prow/hco-e2e-image-index-aws

@kubevirt-bot
Copy link
Contributor

@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-image-index-aws

In response to this:

hco-e2e-image-index-azure, hco-e2e-image-index-gcp lanes succeeded.
/override ci/prow/hco-e2e-image-index-aws

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.

@ovirt-infra
Copy link

All tests passed

1 similar comment
@ovirt-infra
Copy link

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>
@ovirt-infra
Copy link

All tests passed

@tiraboschi tiraboschi changed the title WIP: enqueue for the object that caused the reconciliation Distinguish reconciliation requests triggered by the primary resource from ones triggered by others Nov 6, 2020
@kubevirt-bot kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note-none Denotes a PR that doesn't merit a release note. labels Nov 6, 2020
@ovirt-infra
Copy link

All tests passed

@openshift-merge-robot
Copy link
Collaborator

@tiraboschi: The following test failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
ci/prow/hco-e2e-upgrade-aws 016f255 link /test hco-e2e-upgrade-aws

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-bot
Copy link
Collaborator

hco-bot commented Nov 6, 2020

hco-e2e-upgrade-azure lane succeeded.
/override ci/prow/hco-e2e-upgrade-aws

@kubevirt-bot
Copy link
Contributor

@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-upgrade-aws

In response to this:

hco-e2e-upgrade-azure lane succeeded.
/override ci/prow/hco-e2e-upgrade-aws

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.

@tiraboschi
Copy link
Member Author

Ignoring slightly reduced coverage
/override coverage/coveralls

@kubevirt-bot
Copy link
Contributor

@tiraboschi: Overrode contexts on behalf of tiraboschi: coverage/coveralls

In response to this:

Ignoring slightly reduced coverage
/override coverage/coveralls

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.

Copy link
Collaborator

@nunnatsa nunnatsa left a 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")
Copy link
Collaborator

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?

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Nov 8, 2020
@kubevirt-bot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 8, 2020
@kubevirt-bot kubevirt-bot merged commit dd32e5d into kubevirt:master Nov 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants