Description of problem: Certain resources will return that they have a label present when they do not. # notice how the componentstatus resources claim to have cr_applied label [ec2-user us-east-1 ~]$ oc get ComponentStatus -l cr_applied NAME STATUS MESSAGE ERROR controller-manager Healthy ok scheduler Healthy ok etcd-1 Healthy {"health":"true"} etcd-2 Healthy {"health":"true"} etcd-0 Healthy {"health":"true"} # But do not [ec2-user us-east-1 ~]$ oc get ComponentStatus scheduler -o=yaml apiVersion: v1 conditions: - message: ok status: "True" type: Healthy kind: ComponentStatus metadata: creationTimestamp: null name: scheduler selfLink: /api/v1/componentstatuses/scheduler # Most resources are correctly filtered [ec2-user us-east-1 ~]$ oc get all -l cr_applied No resources found. Version-Release number of selected component (if applicable): version 4.0.0-0.alpha-2019-02-24-225217 How reproducible: 100% Steps to Reproduce: 1. oc get componentstatus -l anylabel 2. 3. Actual results: Componentstatuses are returned though they do not possess the label Expected results: Only resources with the label, regardless of kind, should be returned Additional info:
This should be working in the current version.
Confirmed with latest oc client, can't reproduce the issue now: [root@dhcp-140-138 home]# oc version -o yaml clientVersion: buildDate: "2020-02-28T23:32:38Z" compiler: gc gitCommit: bc08a48555986f64165555efd2705eff7ef2de81 gitTreeState: clean gitVersion: 4.4.0-202002282323-bc08a48 goVersion: go1.13.4 major: "" minor: "" platform: linux/amd64 [root@dhcp-140-138 home]# oc get ComponentStatus -l cr_applied No resources found in default namespace.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0581