Bug 1905040
| Summary: | Inconsistency in naming: cluster-baremetal-operator clusteroperator resource is called just "baremetal" | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Sasha Smolyak <ssmolyak> |
| Component: | Bare Metal Hardware Provisioning | Assignee: | Beth White <beth.white> |
| Bare Metal Hardware Provisioning sub component: | cluster-baremetal-operator | QA Contact: | Amit Ugol <augol> |
| Status: | CLOSED NOTABUG | Docs Contact: | |
| Severity: | unspecified | ||
| Priority: | unspecified | CC: | aos-bugs, shardy, stbenjam |
| Version: | 4.7 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-02-22 19:28:27 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Sasha Smolyak
2020-12-07 11:54:50 UTC
This is consistent with other cluster operators AFAICS, e.g the fully namespaced resource is `oc get clusteroperator/baremetal`
This is the output of oc get clusteroperators
$ oc get co | awk '{print $1}'
NAME
authentication
baremetal
cloud-credential
cluster-autoscaler
config-operator
console
csi-snapshot-controller
dns
etcd
image-registry
ingress
insights
kube-apiserver
kube-controller-manager
kube-scheduler
kube-storage-version-migrator
machine-api
machine-approver
machine-config
marketplace
monitoring
network
node-tuning
openshift-apiserver
openshift-controller-manager
openshift-samples
operator-lifecycle-manager
operator-lifecycle-manager-catalog
operator-lifecycle-manager-packageserver
service-ca
storage
As we can see many/most of the names are similarly abbreviated, so I'm unclear why we'd do something different for the CBO?
When testing cluster-baremetal-operator, we find all the resources of that name, we have a list of them. For serviceaccount and for deployment the name in the list stays the same. In case of clusteroperator the assumption is suddenly broken. Also, it's not reflected in the describing docs, so when looking for the new operator, the user assumes that the naming will be as in the epic describing it. Also, the Manager of provisioning-configuration is written as cluster-baremetal-operator [kni@provisionhost-0-0 ocp-edge-auto]$ oc get deploy NAME READY UP-TO-DATE AVAILABLE AGE cluster-autoscaler-operator 1/1 1 1 5d21h cluster-baremetal-operator 1/1 1 1 5d21h machine-api-controllers 1/1 1 1 5d21h machine-api-operator 1/1 1 1 5d21h metal3 1/1 1 1 5d21h [kni@provisionhost-0-0 ocp-edge-auto]$ oc get sa NAME SECRETS AGE builder 2 5d21h cluster-autoscaler 2 5d21h cluster-autoscaler-operator 2 5d21h cluster-baremetal-operator 2 5d21h default 2 5d21h deployer 2 5d21h machine-api-controllers 2 5d21h [kni@provisionhost-0-0 ocp-edge-auto]$ oc get clusteroperators NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.7.0-0.nightly-2020-11-30-172451 True False False 3d6h baremetal 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h cloud-credential 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h cluster-autoscaler 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h config-operator 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h console 4.7.0-0.nightly-2020-11-30-172451 True False False 5d20h csi-snapshot-controller 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h dns 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h etcd 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h image-registry 4.7.0-0.nightly-2020-11-30-172451 True False False 5d20h ingress 4.7.0-0.nightly-2020-11-30-172451 True False False 5d20h insights 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h kube-apiserver 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h kube-controller-manager 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h kube-scheduler 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h kube-storage-version-migrator 4.7.0-0.nightly-2020-11-30-172451 True False False 5d20h machine-api 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h machine-approver 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h machine-config 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h marketplace 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h monitoring 4.7.0-0.nightly-2020-11-30-172451 True False False 5d20h network 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h node-tuning 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h openshift-apiserver 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h openshift-controller-manager 4.7.0-0.nightly-2020-11-30-172451 True False False 4d21h openshift-samples 4.7.0-0.nightly-2020-11-30-172451 True False False 5d20h operator-lifecycle-manager 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h operator-lifecycle-manager-catalog 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h operator-lifecycle-manager-packageserver 4.7.0-0.nightly-2020-11-30-172451 True False False 5d20h service-ca 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h storage 4.7.0-0.nightly-2020-11-30-172451 True False False 5d21h machine-api-operator 2 5d21h machine-api-termination-handler 2 5d21h In case of cluster-autoscaler we see cluster-autoscaler and cluster-autocsaler-operator. I see that logic. In case of baremetal it's trimmed from every direction and makes it very difficult to read and understand what's dependant on it (In reply to Sasha Smolyak from comment #3) > In case of cluster-autoscaler we see cluster-autoscaler and > cluster-autocsaler-operator. I see that logic. In case of baremetal it's > trimmed from every direction and makes it very difficult to read and > understand what's dependant on it I'm not sure cluster-autoscaler is the best example, it's the only operator in the clusteroperators list which includes the "cluster-" prefix, e.g: $ oc get co -o json | jq -r '.items[].metadata|("\nname : "+.name,.managedFields[].manager)' | grep -v cluster-version-operator name : authentication authentication-operator name : baremetal cluster-baremetal-operator name : cloud-credential cloud-credential-operator name : cluster-autoscaler cluster-autoscaler-operator name : config-operator cluster-config-operator name : console console name : csi-snapshot-controller csi-snapshot-controller-operator name : dns dns-operator name : etcd cluster-etcd-operator name : image-registry cluster-image-registry-operator name : ingress ingress-operator name : insights insights-operator name : kube-apiserver cluster-kube-apiserver-operator name : kube-controller-manager cluster-kube-controller-manager-operator name : kube-scheduler cluster-kube-scheduler-operator name : kube-storage-version-migrator cluster-kube-storage-version-migrator-operator name : machine-api machine-api-operator name : machine-approver machine-approver name : machine-config machine-config-operator name : marketplace marketplace-operator name : monitoring operator name : network cluster-network-operator name : node-tuning cluster-node-tuning-operator name : openshift-apiserver cluster-openshift-apiserver-operator name : openshift-controller-manager cluster-openshift-controller-manager-operator name : openshift-samples cluster-samples-operator name : operator-lifecycle-manager olm name : operator-lifecycle-manager-catalog catalog name : operator-lifecycle-manager-packageserver olm name : service-ca service-ca-operator name : storage cluster-storage-operator As you can see, the majority of other operators do the same as the CBO, e.g strip the leading "cluster-" prefix and "-operator" suffix, and the underlying controller can be observed by looking at the manager field in the clusteroperator output. IMHO it would be better for any automation to rely on this API output, and avoid reliance on hard-coded lists or naming conventions? Going to close this since we match what other cluster operators do, Please re-open if you have more information. Thanks! |