workflow VS strimzi-kafka-operator

Thanks for your really kind post. The other Deis fork, for people that are wondering, is called drycc - https://blog.drycc.cc/2019/02/14/Welcome-to-Drycc/ and I don't hear from them, not sure if they're actively developing, but it sure looks like they are: https://github.com/drycc/workflow committing again yesterday FWIW – our goals and their goals are different, my interest is more like a museum curator, I want to make sure that it's preserved intact for future generations and posterity, but I don't think it will be developed any further except to keep it functioning.

github

Knative dashboards together with Kafka's dashboards it sheds light on almost any aspect of what's going on in the system.

Strimzi is an operator for deploying Kafka in K8s, and makes extensive use of CRs. E.g., https://github.com/strimzi/strimzi-kafka-operator/blob/0.31.1/examples/kafka/kafka-persistent.yaml

But I encountered a problem. In the example files they provide prometheus-additional.yaml file which is referred to in prometheus.yaml as additionalScrapeConfigs field. It collects Kubernetes node metrics for which it has panels in example Grafana dashboards. All good. But the problem is, the prometheus-additional.yaml file has a field called namespaces: names: [] (File can be seen here - https://github.com/strimzi/strimzi-kafka-operator/blob/main/examples/metrics/prometheus-additional-properties/prometheus-additional.yaml) in kubernetes_sd_configs.