I created a pod monitor that needs monitoring/prometheus-operator to be existant.
However Helmfile tells that the release doesn't exist: in ./helmfile.yaml: "kube-system/prometheus-operator-monitors" depends on nonexistent release "monitoring/prometheus-operator"
I created monitoring/prometheus-operator in another Helmfile.
- name: prometheus-operator-monitors
namespace: kube-system
chart: incubator/raw
labels:
component: prometheus-operator-monitors
namespace: monitoring
force: true
needs:
- kube-system/traefik
- monitoring/prometheus-operator
values:
- resources:
- apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: prometheus-traefik-pods-monitor
labels:
release: prometheus-operator
spec:
podMetricsEndpoints:
- path: /metrics
port: traefik
namespaceSelector:
any: true
selector:
matchLabels:
app: traefik
helm ls -A
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
cert-manager cert-manager 19 2020-04-06 16:52:55.804433 +0200 CEST deployed cert-manager-v0.14.1 v0.14.1
cert-manager-issuers cert-manager 18 2020-04-06 16:53:05.31225 +0200 CEST deployed raw-0.2.3 0.2.3
loki monitoring 3 2020-04-06 00:35:45.771259 +0200 CEST deployed loki-stack-0.34.0 v1.4.0
monitoring-certificates monitoring 9 2020-04-06 16:53:15.887974 +0200 CEST deployed raw-0.2.3 0.2.3
prometheus-operator monitoring 10 2020-04-06 16:53:21.816099 +0200 CEST deployed prometheus-operator-8.12.9 0.37.0
prometheus-operator-ingresses monitoring 5 2020-04-06 16:54:09.683268 +0200 CEST deployed raw-0.2.3 0.2.3
prometheus-operator-monitors monitoring 2 2020-04-06 00:41:25.441866 +0200 CEST deployed raw-0.2.3 0.2.3
traefik kube-system 1 2020-04-06 16:58:30.388683 +0200 CEST deployed traefik-7.2.0 2.2.0
Each sub-helmfile is isolated so you can't refer to releases in another helmfile within needs.
Understand. This explains the behavior.
If we had each sub-helmfile in a single file it would be rather large. We're at 16 subfiles and growing. Is there a workaround that would allow us to keep them in seperate files?
I thought about ordering it in our main file like so:
helmfiles:
- path: "releases/foo.yaml"
- path: "releases/Fah_that_requires_foo.yaml"
but I'm not sure if the keys of helmfiles are guaranteed to be operated in order from top to bottom :thinking:
@caleb15 Sub-helmfiles are processed in the order of definition on apply/sync/etc, and in the opposite order on delete/destroy.
Thanks, to clarify by in the order of definition you mean that with something like this:
helmfiles:
- path: "a.yaml"
- path: "b.yaml"
- path: "c.yaml"
when you run a sync a would be processed first, then b, then c, correct?
@caleb15 Yes
Sweet, thanks!