-
Notifications
You must be signed in to change notification settings - Fork 545
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
OCPBUGS-17157: *: label k8s objects we own #3020
OCPBUGS-17157: *: label k8s objects we own #3020
Conversation
@stevekuznetsov: This pull request references Jira Issue OCPBUGS-17157, which is valid. 3 validation(s) were run on this bug
Requesting review from QA contact: The bug has been updated to refer to the pull request using the external bug tracker. 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. |
Need to think about the best way to test this, but code is ready for review. |
12f4b12
to
8685123
Compare
I think I will test this once I add logic to startup that ensures we reach a steady-state where we can filter down the WATCH streams. Will be best to test on upgrade. |
8685123
to
a03d299
Compare
5effa46
to
d15be27
Compare
@stevekuznetsov can you add a high level description of what's happening here? It seems like we're setting up some new informers with an ObjectLabeller syncer, and those syncs are just ensuring a And this is where I'm confused: Why do we need informers and syncers for this? Shouldn't the thing(s) that create/sync these objects in the first place be where the labels are applied? |
We need both - #3017 went in to label new resources we create, but we need this PR to label resources created by older versions of OLM that upgrade to this one. |
d15be27
to
267e59c
Compare
Signed-off-by: Steve Kuznetsov <skuznets@redhat.com>
267e59c
to
00c4845
Compare
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
hasOLMOwnerLabels := true | ||
for _, label := range []string{ownerutil.OwnerKey, ownerutil.OwnerNamespaceKey, ownerutil.OwnerKind} { | ||
_, exists := object.GetLabels()[label] | ||
hasOLMOwnerLabels = hasOLMOwnerLabels && exists | ||
} | ||
return hasOLMOwnerLabels |
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.
Nit: Is there a reason you chose not to exit early if the label is missing?
hasOLMOwnerLabels := true | |
for _, label := range []string{ownerutil.OwnerKey, ownerutil.OwnerNamespaceKey, ownerutil.OwnerKind} { | |
_, exists := object.GetLabels()[label] | |
hasOLMOwnerLabels = hasOLMOwnerLabels && exists | |
} | |
return hasOLMOwnerLabels | |
for _, label := range []string{ownerutil.OwnerKey, ownerutil.OwnerNamespaceKey, ownerutil.OwnerKind} { | |
if _, exists := object.GetLabels()[label]; !exists { | |
return false | |
} | |
} | |
return true |
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.
Since N=3 I don't know that it makes any meaningful difference
@@ -481,6 +519,18 @@ func newOperatorWithConfig(ctx context.Context, config *operatorConfig) (*Operat | |||
return nil, err | |||
} | |||
|
|||
if err := labelObjects(rbacv1.SchemeGroupVersion.WithResource("clusterroles"), clusterRoleInformer.Informer(), labeller.ObjectLabeler[*rbacv1.ClusterRole, *rbacv1applyconfigurations.ClusterRoleApplyConfiguration]( | |||
ctx, op.logger, labeller.HasOLMOwnerRef, | |||
func(name, _ string) *rbacv1applyconfigurations.ClusterRoleApplyConfiguration { |
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.
Cool, I haven't seen _ string
used before.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: awgreene, stevekuznetsov 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 |
Nice work @stevekuznetsov, thanks for the PR. |
/lgtm |
c55c24d
into
operator-framework:master
No description provided.