Refactor trovilo job design

[johscheuer]

Currently trovilo supports multiple jobs (e.g. to gather information for Prometheus and for Grafana) since trovilo is designed to run inside Kubernetes environments I don't actaully see a benefit in supporting multiple jobs (and adding the complexity). From my perspective trovilo should always be used as a sidecar to the according service like in the Prometheus example: https://github.com/inovex/trovilo/blob/master/examples/k8s/deployment.yaml#L60

Are there any reasons why we should keep to support multiple jobs?

[arnisoph]

I see some use cases, but before writing some of them down I would be interested in the motivation behind your question. :) (next to making the code more simple)

[hikhvar]

To fully support the multijob feature with different label selectors we should open one watch per job. This requires a rework of the trovilo core. Hence we should decide if we need the complexity in the code or just use multiple trovilo sidecar instances for multiple jobs.

[johscheuer]

From my perspective at-least the namespace selection should be moved inside the job section since I wouldn't assume that all configmaps are in the same namespace if I actually want to use multiple job (and currently I don't see any use case that couldn't be solved using multiple sidecars e.g. for Prometheus/Grafana etc.). Also the additional sidecars have a really low compute footprint since they only do stuff if a specific configmap was changed/added/deleted. Also I would trade code simplicity (and robustness) over a functionality that can be solved by starting multiple instances/sidecars of trovilo.

[arnisoph]

Regarding namespace: 👍 Can you show an updated version of the config example (see README) please so we all have the same picture about the resulting configuration file/DSL?

[johscheuer]

I would go with something like this (one job per instance):

name: alert-rules
selector:
  type: prometheus-alerts
verify:
  - name: verify alert rule validity
    cmd: ["promtool", "check", "rules", "%s"]
target-dir: /etc/prometheus-alerts/
flatten: true
post-deploy:
  - name: reload prometheus
    cmd: ["curl", "-s", "-X", "POST", "http://localhost:9090/-/reload"]

[arnisoph]

We already have cmd line flags but I'd like to keep other (global, non-redundant) options possible. Just thinking about stuff with newlines or more complex options..

What do you think?

job:
  name: alert-rules
  #namespace: ""
  selector:
    type: prometheus-alerts
  verify:
    - name: verify alert rule validity
      cmd: ["promtool", "check", "rules", "%s"]
  target-dir: /etc/prometheus-alerts/
  flatten: true
  post-deploy:
    - name: reload prometheus
      cmd: ["curl", "-s", "-X", "POST", "http://localhost:9090/-/reload"]