Flake: TestSyncOperatorGroups/AllNamespaces/CSVPresent/InstallModeNotSupported #2091
Assignees
Labels
kind/bug
Categorizes issue or PR as related to a bug.
kind/flake
Categorizes issue or PR as related to a flaky test.
Milestone
Comments
This was referenced May 10, 2021
5 tasks
5 tasks
|
Saw a new failure in https://github.com/operator-framework/operator-lifecycle-manager/runs/3243630835?check_suite_focus=true#step:5:1356: |
This was referenced Sep 8, 2021
timflannagan
added a commit
to timflannagan/operator-lifecycle-manager
that referenced
this issue
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.
5 tasks
timflannagan
added a commit
to timflannagan/operator-lifecycle-manager
that referenced
this issue
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 issue
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 <[email protected]>
timflannagan
added a commit
to timflannagan/operator-lifecycle-manager
that referenced
this issue
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 <[email protected]>
5 tasks
timflannagan
added a commit
to timflannagan/operator-lifecycle-manager
that referenced
this issue
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 <[email protected]>
timflannagan
added a commit
to timflannagan/operator-lifecycle-manager
that referenced
this issue
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 <[email protected]>
timflannagan
added a commit
to timflannagan/operator-lifecycle-manager
that referenced
this issue
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 <[email protected]>
openshift-merge-robot
pushed a commit
that referenced
this issue
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 <[email protected]> * test(og): de-flake sync unit tests Co-authored-by: Nick Hale <[email protected]>
njhale
added a commit
to njhale/operator-framework-olm
that referenced
this issue
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 <[email protected]> * test(og): de-flake sync unit tests Co-authored-by: Nick Hale <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
njhale
added a commit
to njhale/operator-framework-olm
that referenced
this issue
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 <[email protected]> * test(og): de-flake sync unit tests Co-authored-by: Nick Hale <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
timflannagan
added a commit
to njhale/operator-framework-olm
that referenced
this issue
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 <[email protected]> * test(og): de-flake sync unit tests Co-authored-by: Nick Hale <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
timflannagan
added a commit
to njhale/operator-framework-olm
that referenced
this issue
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 <[email protected]> * test(og): de-flake sync unit tests Co-authored-by: Nick Hale <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
perdasilva
pushed a commit
to perdasilva/operator-framework-olm
that referenced
this issue
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 <[email protected]> * test(og): de-flake sync unit tests Co-authored-by: Nick Hale <[email protected]> Upstream-repository: operator-lifecycle-manager Upstream-commit: 188ee1ae265f0a79d90b4cce52d97a26f16afe5a
perdasilva
pushed a commit
to perdasilva/operator-framework-olm
that referenced
this issue
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 <[email protected]> * test(og): de-flake sync unit tests Co-authored-by: Nick Hale <[email protected]> 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
Seen this a couple times now, most recently in https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/operator-framework_operator-lifecycle-manager/2090/pull-ci-operator-framework-operator-lifecycle-manager-master-unit/1380237274532286464#1:build-log.txt%3A969.
The text was updated successfully, but these errors were encountered: