The current configuration of the operator controller manager contains labels that cause incorrect pod references when multiple operator controller managers are present. The labels need to be updated to ensure proper identification and management of pods by different operator controllers.
:construction:
track operators:
[x] zncdatadev/commons-operator#28
[x] zncdatadev/listener-operator#73
[x] zncdatadev/secret-operator#77
[x] zncdatadev/trino-operator#109 (trino)
[x] zncdatadev/zookeeper-operator#51
[x] zncdatadev/hdfs-operator#43
[x] zncdatadev/kafka-operator/pull/53
[x] zncdatadev/hbase-operator/pull/40
[x] zncdatadev/superset-operator/pull/41
[x] zncdatadev/dolphinscheduler-operator/pull/44
[x] zncdatadev/spark-k8s-operator/pull/90
[x] zncdatadev/hive-operator/pull/92
Examples 🌈
The following changes are proposed to the config/manager/manager.yaml file to correct the label issue:
When multiple operator controller managers are deployed in the same cluster, the current labels in the configuration file cause conflicts due to ambiguous references. Specifically, the labels control-plane: controller-manager and app.kubernetes.io/name: deployment are too generic and can lead to pods being incorrectly managed by the wrong operator controller. By updating the labels to more specific values such as control-plane: hdfs-operator and app.kubernetes.io/name: hdfs-operator, we can ensure that pods are correctly referenced and managed by the appropriate operator controller manager, thus preventing conflicts and ensuring the stability of the deployment.
Duplicates
I have searched the existing issues
Summary 💡
The current configuration of the operator controller manager contains labels that cause incorrect pod references when multiple operator controller managers are present. The labels need to be updated to ensure proper identification and management of pods by different operator controllers.
:construction: track operators:
Examples 🌈
The following changes are proposed to the config/manager/manager.yaml file to correct the label issue:
Motivation 🔦
When multiple operator controller managers are deployed in the same cluster, the current labels in the configuration file cause conflicts due to ambiguous references. Specifically, the labels control-plane: controller-manager and app.kubernetes.io/name: deployment are too generic and can lead to pods being incorrectly managed by the wrong operator controller. By updating the labels to more specific values such as control-plane: hdfs-operator and app.kubernetes.io/name: hdfs-operator, we can ensure that pods are correctly referenced and managed by the appropriate operator controller manager, thus preventing conflicts and ensuring the stability of the deployment.