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

common-instancetypes: Ignore attempts to reconcile virt-operator owned objects from bundle #661

Conversation

lyarwood
Copy link
Member

@lyarwood lyarwood commented Aug 16, 2023

What this PR does / why we need it:

This PR introduces IgnoreObjectOwnedByVirtOperator to reconcileBuilder that as the name suggests ignores attempts to reconcile resources that are labelled as being owned by KubeVirt's virt-operator.

This is then used by the common-instancetypes operand ahead of deployment of these resources being enabled through virt-operator by kubevirt/kubevirt#10309.

Future changes will also introduce a configurable to disable common-instancetypes deployment within SSP and ultimately deprecate the functionality ahead of removal in a future release of SSP.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Release note:

NONE

@kubevirt-bot kubevirt-bot added dco-signoff: yes Indicates the PR's author has DCO signed all their commits. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. 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 Aug 16, 2023
@openshift-ci
Copy link

openshift-ci bot commented Aug 16, 2023

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@lyarwood lyarwood force-pushed the common-instancetypes-ignore-virt-operator-resources branch from e51cb67 to 441a305 Compare August 16, 2023 16:40
@sonarcloud
Copy link

sonarcloud bot commented Aug 16, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

No Coverage information No Coverage information
0.0% 0.0% Duplication

@@ -161,6 +167,11 @@ func (r *reconcileBuilder) Options(options ReconcileOptions) ReconcileBuilder {
return r
}

func (r *reconcileBuilder) IgnoreObjectOwnedByVirtOperator() ReconcileBuilder {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW if folks think we might need to ignore other types of resource in the future I can make this more generic passing a function as with the UpdateFunc and StatusFunc methods but at the moment I think it's better to be explicit.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO this is too specific to be in the reconcileBuilder. Can you move the logic to the functions that reconcile InstanceTypes and Preferences? reconcileVirtualMachineClusterInstancetypesFuncs() and reconcileVirtualMachineClusterPreferencesFuncs()

There you can check if the resource is owned by virt-operator or not.

@lyarwood
Copy link
Member Author

I'll respin with more tests later today but comments welcome in the meantime.

@@ -15,6 +15,7 @@ import (
rbac "k8s.io/api/rbac/v1"
"k8s.io/apimachinery/pkg/api/equality"
"k8s.io/apimachinery/pkg/api/errors"
kubevirtCorev1 "kubevirt.io/api/core/v1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Import as kvirtv1?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about kubevirtv1?

$ git grep -h "kubevirt.io/api/core/v1" | awk '{ print $1 }' | sort | uniq
corev1
k6tv1
kubevirt
kubevirtCorev1
kubevirt.io/api/core/v1
kubevirtv1
v1

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or just virtv1, that's what's used in kubevirt/kubevirt a lot.

// During an upgrade to v0.19.0 we might encounter virt-operator attempting
// to reconcile the same set of common-instancetype resources. If configured
// ignore these requests to reconcile such objects once owned by virt-operator
if r.options.IgnoreObjectOwnedByVirtOperator && isOwnedByVirtOperator(existing) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put this at the start of Reconcile instead to short-circuit the whole reconciliation?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to put objects owned by virt-operator into the VersionCache?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving this earlier would cause another client lookup for every object for every reconcile. We can move this but I'm not sure it's worth it.

In terms of the VersionCache yeah we can avoid this but AFAICT there's no impact of this being registered?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, then let's keep it here.

Just wanted to make sure we don't create any issues by caching resources we do not own.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving this earlier would cause another client lookup for every object for every reconcile. We can move this but I'm not sure it's worth it.

Client lookups are cheap, because everything is cached in memory. The API client watches the cluster, and any Get() or List() function calls just read the cahce.

@0xFelix
Copy link
Member

0xFelix commented Aug 17, 2023

Can / should we test that SSP still reaches phase Deployed when virt-operator takes over?

@lyarwood
Copy link
Member Author

Can / should we test that SSP still reaches phase Deployed when virt-operator takes over?

Yup that's easy enough to mock in an e2e test and would give us coverage in SSP without needing HCO or an updated virt-operator.

@lyarwood lyarwood force-pushed the common-instancetypes-ignore-virt-operator-resources branch from 441a305 to 02f76a1 Compare October 11, 2023 14:21
@lyarwood lyarwood marked this pull request as ready for review October 11, 2023 14:22
@kubevirt-bot kubevirt-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 11, 2023
@github-actions
Copy link

/cc sradco

@lyarwood
Copy link
Member Author

/hold cancel

@kubevirt-bot kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 11, 2023
Copy link
Member

@0xFelix 0xFelix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you still going to add an e2e for the upgrade scenario?

@@ -391,6 +418,10 @@ func logOperation(result OperationResult, resource client.Object, logger logr.Lo
logger.Info(fmt.Sprintf("Deleted %s resource: %s",
resource.GetObjectKind().GroupVersionKind().Kind,
resource.GetName()))
case OperationResultIgnored:
logger.Info(fmt.Sprintf("Ignored %s resource: %s",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
logger.Info(fmt.Sprintf("Ignored %s resource: %s",
logger.Info(fmt.Sprintf("Ignored %s resource owned by virt-operator: %s",

WDYT?

@0xFelix 0xFelix force-pushed the common-instancetypes-ignore-virt-operator-resources branch from 02f76a1 to 7f6d954 Compare October 23, 2023 12:48
@github-actions
Copy link

/cc sradco

Copy link
Collaborator

@akrejcir akrejcir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this logic can be moved to specific reconcile functions.

Have you considered removing the SSP owner annotations from the InstanceTypes and Preferences that are owned by virt-operator? Then they would no longer trigger SSP reconciliation.

@@ -161,6 +167,11 @@ func (r *reconcileBuilder) Options(options ReconcileOptions) ReconcileBuilder {
return r
}

func (r *reconcileBuilder) IgnoreObjectOwnedByVirtOperator() ReconcileBuilder {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO this is too specific to be in the reconcileBuilder. Can you move the logic to the functions that reconcile InstanceTypes and Preferences? reconcileVirtualMachineClusterInstancetypesFuncs() and reconcileVirtualMachineClusterPreferencesFuncs()

There you can check if the resource is owned by virt-operator or not.

// During an upgrade to v0.19.0 we might encounter virt-operator attempting
// to reconcile the same set of common-instancetype resources. If configured
// ignore these requests to reconcile such objects once owned by virt-operator
if r.options.IgnoreObjectOwnedByVirtOperator && isOwnedByVirtOperator(existing) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving this earlier would cause another client lookup for every object for every reconcile. We can move this but I'm not sure it's worth it.

Client lookups are cheap, because everything is cached in memory. The API client watches the cluster, and any Get() or List() function calls just read the cahce.

if obj.GetLabels() == nil {
return false
}
managedValue, managedOk := obj.GetLabels()[kubevirtCorev1.ManagedByLabel]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use constant AppKubernetesManagedByLabel, instead of the imported one kubevirtCorev1.ManagedByLabel.

@0xFelix 0xFelix force-pushed the common-instancetypes-ignore-virt-operator-resources branch from 7f6d954 to 434d4c5 Compare October 24, 2023 11:25
@github-actions
Copy link

/cc sradco

@0xFelix
Copy link
Member

0xFelix commented Oct 24, 2023

Have you considered removing the SSP owner annotations from the InstanceTypes and Preferences that are owned by virt-operator? Then they would no longer trigger SSP reconciliation.

virt-operator reconstructs the metadata of objects during reconciliation, so this should already be the case.

internal/common/resource.go Outdated Show resolved Hide resolved
internal/operands/common-instancetypes/reconcile.go Outdated Show resolved Hide resolved
internal/operands/common-instancetypes/reconcile.go Outdated Show resolved Hide resolved
internal/operands/common-instancetypes/reconcile.go Outdated Show resolved Hide resolved
internal/operands/common-instancetypes/reconcile_test.go Outdated Show resolved Hide resolved
@0xFelix 0xFelix force-pushed the common-instancetypes-ignore-virt-operator-resources branch from 434d4c5 to ed32b16 Compare October 24, 2023 13:30
With this change the common-instancetypes operand ignores resources that
are labelled as being owned by KubeVirt's virt-operator during
reconciliation.

Co-authored-by: Lee Yarwood <[email protected]>
Signed-off-by: Felix Matouschek <[email protected]>
@0xFelix 0xFelix force-pushed the common-instancetypes-ignore-virt-operator-resources branch from ed32b16 to 87edf8d Compare October 25, 2023 14:19
@sonarcloud
Copy link

sonarcloud bot commented Oct 25, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@akrejcir
Copy link
Collaborator

/lgtm
/approve

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Oct 25, 2023
@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: akrejcir

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 Oct 25, 2023
@kubevirt-bot kubevirt-bot merged commit 004dfe4 into kubevirt:main Oct 25, 2023
14 checks passed
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-none Denotes a PR that doesn't merit a release note. size/L
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants