-
Notifications
You must be signed in to change notification settings - Fork 47
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
common-instancetypes: Ignore attempts to reconcile virt-operator owned objects from bundle #661
Conversation
Skipping CI for Draft Pull Request. |
e51cb67
to
441a305
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
internal/common/resource.go
Outdated
@@ -161,6 +167,11 @@ func (r *reconcileBuilder) Options(options ReconcileOptions) ReconcileBuilder { | |||
return r | |||
} | |||
|
|||
func (r *reconcileBuilder) IgnoreObjectOwnedByVirtOperator() ReconcileBuilder { |
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.
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.
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.
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.
I'll respin with more tests later today but comments welcome in the meantime. |
internal/common/resource.go
Outdated
@@ -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" |
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.
Import as kvirtv1
?
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.
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
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.
Or just virtv1
, that's what's used in kubevirt/kubevirt a lot.
internal/common/resource.go
Outdated
// 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) { |
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.
Put this at the start of Reconcile
instead to short-circuit the whole reconciliation?
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.
Do we want to put objects owned by virt-operator into the VersionCache
?
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.
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?
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.
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.
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.
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.
Can / should we test that SSP still reaches phase |
Yup that's easy enough to mock in an e2e test and would give us coverage in SSP without needing HCO or an updated |
441a305
to
02f76a1
Compare
/cc sradco |
/hold cancel |
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.
Are you still going to add an e2e for the upgrade scenario?
internal/common/resource.go
Outdated
@@ -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", |
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.
logger.Info(fmt.Sprintf("Ignored %s resource: %s", | |
logger.Info(fmt.Sprintf("Ignored %s resource owned by virt-operator: %s", |
WDYT?
02f76a1
to
7f6d954
Compare
/cc sradco |
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 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.
internal/common/resource.go
Outdated
@@ -161,6 +167,11 @@ func (r *reconcileBuilder) Options(options ReconcileOptions) ReconcileBuilder { | |||
return r | |||
} | |||
|
|||
func (r *reconcileBuilder) IgnoreObjectOwnedByVirtOperator() ReconcileBuilder { |
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.
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.
internal/common/resource.go
Outdated
// 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) { |
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.
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.
internal/common/resource.go
Outdated
if obj.GetLabels() == nil { | ||
return false | ||
} | ||
managedValue, managedOk := obj.GetLabels()[kubevirtCorev1.ManagedByLabel] |
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 can use constant AppKubernetesManagedByLabel
, instead of the imported one kubevirtCorev1.ManagedByLabel
.
7f6d954
to
434d4c5
Compare
/cc sradco |
virt-operator reconstructs the metadata of objects during reconciliation, so this should already be the case. |
434d4c5
to
ed32b16
Compare
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]>
ed32b16
to
87edf8d
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
/lgtm |
[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 |
What this PR does / why we need it:
This PR introduces
IgnoreObjectOwnedByVirtOperator
toreconcileBuilder
that as the name suggests ignores attempts to reconcile resources that are labelled as being owned by KubeVirt'svirt-operator
.This is then used by the
common-instancetypes
operand ahead of deployment of these resources being enabled throughvirt-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: