Description of problem: In previous versions of 4.x I believe the machine.openshift.io/cluster-api-machine-type label was set on all machine resources. Now, machine resources no longer have a machine.openshift.io/cluster-api-machine-type label. As of last Friday, I found that selecting on this label is no longer working. Machinesets, do have this label however, and I would expect any/all labels on a machineset to be propagated to machines. The use case is targeting all worker machines for inspection and/or determining if the machineset and machines are in-sync, and if the machines need to be recreated after updating a machineset. How reproducible: Very. Steps to Reproduce: 1. Run kubectl -n openshift-machine-api get machines -l machine.openshift.io/cluster-api-machine-role=worker and see no machines returned. Actual results: Command returns `no resources found`. Expected results: Command returns a list of machines that are workers. Additional info:
After more investigation, the actual issue is with the the machinesets. They no longer have the machine.openshift.io/cluster-api-machine-type label, which is why the machines no longer have the label. bash-4.2$ kubectl -n openshift-machine-api get machinesets --show-labels NAME DESIRED CURRENT READY AVAILABLE AGE LABELS ci-op-27csxzbh-66b3b-qvxxs-worker-us-east-1a 1 1 47m machine.openshift.io/cluster-api-cluster=ci-op-27csxzbh-66b3b-qvxxs ci-op-27csxzbh-66b3b-qvxxs-worker-us-east-1b 1 1 47m machine.openshift.io/cluster-api-cluster=ci-op-27csxzbh-66b3b-qvxxs ci-op-27csxzbh-66b3b-qvxxs-worker-us-east-1c 1 1 47m machine.openshift.io/cluster-api-cluster=ci-op-27csxzbh-66b3b-qvxxs
Looks like those were dropped on AWS in http://github.com/openshift/installer/pull/1474 , although I haven't read the backstory.
Hi Chance, `machine.openshift.io/cluster-api-machine-role` label was used in the past to determine the right security group(s) and subnet(s) for individual AWS instances. The mechanism of determining the right SGs and subnets changed. Yet, we kept `machine.openshift.io/cluster-api-machine-role` label under assumption it's needed by other component. After some investigation we found out it's not actually used and it might be confusing to keep the label there. If you need to list all worker nodes, you can query for `node-role.kubernetes.io/worker` instead. I.e. `kubectl -n openshift-machine-api get machines -l node-role.kubernetes.io/worker=""` Would that be a sufficient resolution for your issue?
That only works for nodes, not machines. Machines only have the `machine.openshift.io/cluster-api-cluster` label. So your suggestion does not work.
https://github.com/openshift/installer/pull/1686
Verified in 4.1.0-0.nightly-2019-05-04-054221 # oc get machinesets --show-labels NAME DESIRED CURRENT READY AVAILABLE AGE LABELS jhou1-j4fzc-worker-ap-northeast-1a 1 1 1 1 112m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc jhou1-j4fzc-worker-ap-northeast-1c 1 1 1 1 112m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc jhou1-j4fzc-worker-ap-northeast-1d 1 1 1 1 112m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc # oc get machines --show-labels NAME INSTANCE STATE TYPE REGION ZONE AGE LABELS jhou1-j4fzc-master-0 i-0c5e3131ee0bf7895 running m4.xlarge ap-northeast-1 ap-northeast-1a 115m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc,machine.openshift.io/cluster-api-machine-role=master,machine.openshift.io/cluster-api-machine-type=master jhou1-j4fzc-master-1 i-06a0f4a55709e4080 running m4.xlarge ap-northeast-1 ap-northeast-1c 115m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc,machine.openshift.io/cluster-api-machine-role=master,machine.openshift.io/cluster-api-machine-type=master jhou1-j4fzc-master-2 i-07bb4440663408971 running m4.xlarge ap-northeast-1 ap-northeast-1d 115m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc,machine.openshift.io/cluster-api-machine-role=master,machine.openshift.io/cluster-api-machine-type=master jhou1-j4fzc-worker-ap-northeast-1a-dxd9h i-04b547dcb8c4b0a79 running m4.large ap-northeast-1 ap-northeast-1a 113m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc,machine.openshift.io/cluster-api-machine-role=worker,machine.openshift.io/cluster-api-machine-type=worker,machine.openshift.io/cluster-api-machineset=jhou1-j4fzc-worker-ap-northeast-1a jhou1-j4fzc-worker-ap-northeast-1c-7xmzk i-07f1df0fa1a014efc running m4.large ap-northeast-1 ap-northeast-1c 113m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc,machine.openshift.io/cluster-api-machine-role=worker,machine.openshift.io/cluster-api-machine-type=worker,machine.openshift.io/cluster-api-machineset=jhou1-j4fzc-worker-ap-northeast-1c jhou1-j4fzc-worker-ap-northeast-1d-tfdm7 i-0c9e995c376cbbae6 running m4.large ap-northeast-1 ap-northeast-1d 113m machine.openshift.io/cluster-api-cluster=jhou1-j4fzc,machine.openshift.io/cluster-api-machine-role=worker,machine.openshift.io/cluster-api-machine-type=worker,machine.openshift.io/cluster-api-machineset=jhou1-j4fzc-worker-ap-northeast-1d
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-2019:0758