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

don't return an error if the singleton rbac doesn't exist #2309

Merged
merged 1 commit into from
Jul 31, 2021

Conversation

ecordell
Copy link
Member

@ecordell ecordell commented Jul 30, 2021

Description of the change:
Doesn't return an error from ensureSingletonRBAC if we can detect that the cache is just a bit behind

Motivation for the change:
Fixes #2091

prior to this change, I could reproduce with:

$ go test ./pkg/controller/operators/olm/... -v -run ^TestSyncOperatorGroups$ -count 10

after this change, I couldn't reproduce with:

$ go test ./pkg/controller/operators/olm/... -v -run ^TestSyncOperatorGroups$ -count 100

Reviewer Checklist

  • Implementation matches the proposed design, or proposal is updated to match implementation
  • Sufficient unit test coverage
  • Sufficient end-to-end test coverage
  • Docs updated or added to /doc
  • Commit messages sensible and descriptive

Signed-off-by: Evan <cordell.evan@gmail.com>
@openshift-ci openshift-ci bot requested review from anik120 and benluddy July 30, 2021 22:11
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 30, 2021
Comment on lines +491 to +495
if k8serrors.IsAlreadyExists(err) && ownerutil.IsOwnedByLabel(cr, csv) {
continue
} else {
return err
}
Copy link
Contributor

Choose a reason for hiding this comment

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

nit:

Suggested change
if k8serrors.IsAlreadyExists(err) && ownerutil.IsOwnedByLabel(cr, csv) {
continue
} else {
return err
}
if k8serrors.IsAlreadyExists(err) && ownerutil.IsOwnedByLabel(cr, csv) {
continue
}
return err

@timflannagan
Copy link
Contributor

timflannagan commented Jul 30, 2021

Nice 😎
Holding for another opinion (if needed - feel free to remove) but this looks reasonable.

/lgtm
/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 30, 2021
@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jul 30, 2021
Copy link
Member

@dinhxuanvu dinhxuanvu left a comment

Choose a reason for hiding this comment

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

/lgtm

@dinhxuanvu
Copy link
Member

This PR failed one e2e test creation with nodeSelector config.

Copy link
Member

@njhale njhale 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 it's also time to resurrect the flake analyzer

@openshift-ci
Copy link

openshift-ci bot commented Jul 31, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dinhxuanvu, ecordell, njhale

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

@njhale
Copy link
Member

njhale commented Jul 31, 2021

/lgtm
/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 31, 2021
@openshift-ci openshift-ci bot merged commit 538b131 into operator-framework:master Jul 31, 2021
timflannagan added a commit to timflannagan/operator-lifecycle-manager that referenced this pull request Sep 8, 2021
…troller

Fixes [operator-framework#2091](operator-framework#2091).

This is a follow-up to [operator-framework#2309](operator-framework#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to instead use the static type instead to avoid a panic.
timflannagan added a commit to timflannagan/operator-lifecycle-manager that referenced this pull request Sep 8, 2021
…troller

Fixes [operator-framework#2091](operator-framework#2091).

This is a follow-up to [operator-framework#2309](operator-framework#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to instead use the static type instead to avoid a panic.
timflannagan added a commit to timflannagan/operator-lifecycle-manager that referenced this pull request Sep 8, 2021
…troller

Fixes [operator-framework#2091](operator-framework#2091).

This is a follow-up to [operator-framework#2309](operator-framework#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to instead use the static type instead to avoid a panic.

Signed-off-by: timflannagan <timflannagan@gmail.com>
timflannagan added a commit to timflannagan/operator-lifecycle-manager that referenced this pull request Sep 8, 2021
…troller

Fixes [operator-framework#2091](operator-framework#2091).

This is a follow-up to [operator-framework#2309](operator-framework#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to instead use the static type instead to avoid a panic.

Signed-off-by: timflannagan <timflannagan@gmail.com>
timflannagan added a commit to timflannagan/operator-lifecycle-manager that referenced this pull request Sep 14, 2021
…troller

Fixes [operator-framework#2091](operator-framework#2091).

This is a follow-up to [operator-framework#2309](operator-framework#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>
timflannagan added a commit to timflannagan/operator-lifecycle-manager that referenced this pull request Sep 14, 2021
…troller

Fixes [operator-framework#2091](operator-framework#2091).

This is a follow-up to [operator-framework#2309](operator-framework#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>
timflannagan added a commit to timflannagan/operator-lifecycle-manager that referenced this pull request Sep 23, 2021
…troller

Fixes [operator-framework#2091](operator-framework#2091).

This is a follow-up to [operator-framework#2309](operator-framework#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>
openshift-merge-robot pushed a commit that referenced this pull request Sep 23, 2021
…troller (#2349)

* pkg/controller: Fix panic when creating cluster-scoped RBAC in OG controller

Fixes [#2091](#2091).

This is a follow-up to [#2309](#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>

* test(og): de-flake sync unit tests

Co-authored-by: Nick Hale <njohnhale@gmail.com>
njhale added a commit to njhale/operator-framework-olm that referenced this pull request Nov 2, 2021
…troller (#2349)

* pkg/controller: Fix panic when creating cluster-scoped RBAC in OG controller

Fixes [#2091](operator-framework/operator-lifecycle-manager#2091).

This is a follow-up to [#2309](operator-framework/operator-lifecycle-manager#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>

* test(og): de-flake sync unit tests

Co-authored-by: Nick Hale <njohnhale@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
njhale added a commit to njhale/operator-framework-olm that referenced this pull request Nov 8, 2021
…troller (#2349)

* pkg/controller: Fix panic when creating cluster-scoped RBAC in OG controller

Fixes [#2091](operator-framework/operator-lifecycle-manager#2091).

This is a follow-up to [#2309](operator-framework/operator-lifecycle-manager#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>

* test(og): de-flake sync unit tests

Co-authored-by: Nick Hale <njohnhale@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
timflannagan added a commit to njhale/operator-framework-olm that referenced this pull request Nov 15, 2021
…troller (#2349)

* pkg/controller: Fix panic when creating cluster-scoped RBAC in OG controller

Fixes [#2091](operator-framework/operator-lifecycle-manager#2091).

This is a follow-up to [#2309](operator-framework/operator-lifecycle-manager#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>

* test(og): de-flake sync unit tests

Co-authored-by: Nick Hale <njohnhale@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
timflannagan added a commit to njhale/operator-framework-olm that referenced this pull request Nov 15, 2021
…troller (#2349)

* pkg/controller: Fix panic when creating cluster-scoped RBAC in OG controller

Fixes [#2091](operator-framework/operator-lifecycle-manager#2091).

This is a follow-up to [#2309](operator-framework/operator-lifecycle-manager#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>

* test(og): de-flake sync unit tests

Co-authored-by: Nick Hale <njohnhale@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
perdasilva pushed a commit to perdasilva/operator-framework-olm that referenced this pull request Mar 4, 2022
…troller (#2349)

* pkg/controller: Fix panic when creating cluster-scoped RBAC in OG controller

Fixes [#2091](operator-framework/operator-lifecycle-manager#2091).

This is a follow-up to [#2309](operator-framework/operator-lifecycle-manager#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>

* test(og): de-flake sync unit tests

Co-authored-by: Nick Hale <njohnhale@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
perdasilva pushed a commit to perdasilva/operator-framework-olm that referenced this pull request Mar 4, 2022
…troller (#2349)

* pkg/controller: Fix panic when creating cluster-scoped RBAC in OG controller

Fixes [#2091](operator-framework/operator-lifecycle-manager#2091).

This is a follow-up to [#2309](operator-framework/operator-lifecycle-manager#2309) that attempted to fix the original issue. When checking whether the ClusterRole/ClusterRoleBinding resources already exist, we're also checking whether the existing labels are owned by the CSV we're currently handling. When accessing the "cr" or "crb" variables that the Create calls output, a panic is produced as we're attempting to access the meta.Labels key from those resources, except those resources themselves are nil. Update the check to verify that the cr/crb variables are not nil before attempting to access those object's labels. The testing fake client may need to be updated in the future to handle returning these resources properly.

Signed-off-by: timflannagan <timflannagan@gmail.com>

* test(og): de-flake sync unit tests

Co-authored-by: Nick Hale <njohnhale@gmail.com>
Upstream-repository: operator-lifecycle-manager
Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
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. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Flake: TestSyncOperatorGroups/AllNamespaces/CSVPresent/InstallModeNotSupported
4 participants