Define commodore component naming

[marcofl]

Define how we name commodore components and:

• where the name comes from
• that the name implies what a component contains

Maybe something like this, example (synsights):

• synsights-metrics
  • Kind: Prometheus (the SYN prometheus instance), namespace: syn-synsights
  • Kind: Alertmanager (the SYN Alertmanager), namespace: syn-synsights
  • Deployment: Pushgateway, namespace: syn-synsights
  • with corresponding Service and Route / Ingress to make it available at least within the cluster
  • Kind: ServiceMonitor to scrape the pushgateway, namespace: syn-synsights
  • Deployment: Blackbox_exporter, namespace: syn-synsights
• openshift4-monitoring, namespace: syn-synsights
  • Kind: ServiceMonitor to federate with openshift managed cluster prometheus
  • Kind: AlertRule for openshift specific alerts
  • configuration needed to actually enable the OpenShift cluster prometheus, etc.
• node-monitoring, namespace: syn-synsights
  • Kind: DaemonSet for node_exporter
  • Kind: ServiceMonitor for node_exporter
  • Alter rules for node specific alerts, e.g. disk space of system disk, load, memory usage, network stats
• kube-monitoring, namespace: syn-synsights
  • Kind: DaemonSet for "kube exporters"
  • Kind: ServiceMonitor for "kube exporters"
  • Alert rules for kubernetes component specific alerts, e.g. etcd, number of nodes, scheduler stuff, kublet running, etc.

Besides monitoring, these could look like this:

• node-maintenance
  • install and configure the "node agent" for automated "apt-get dist-upgrade"
• node-config
  • install and configure the "node agent" to do base setup stuff on the VMs like NTP, SSH, user accounts, etc.
• openshift4-oauth
• openshift4-whatever

[tobru]

This is already in place.