[stable/prometheus-operator] Remove dependencies to support the chart being used in an umbrella chart

[blacksails]

Is this a request for help?: No

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST

Prometheus operator is a component that a lot of people consider a core part of setting up a kubernetes cluster. Therefore it should be able to use it in an umbrella chart. To my understanding there is currently issues with enabling/disabling subsubcharts through requirement conditions. This means that the only viable solution would be to not have those dependencies in the chart.

Version of Helm and Kubernetes: Helm 2.11.0, K8s 1.11.2

Which chart: stable/prometheus-operator

What happened:
I tried to use the chart in our organization umbrella chart, and tried to disable grafana by setting

prometheus-operator:
  grafana:
    enabled: false

I suspect this is currently not supported due to this issue: helm/helm#2479

What you expected to happen:
I would expect that non of the resources from the grafana subsubchart would be generated.

How to reproduce it (as minimally and precisely as possible):
Depend on the chart in an umbrella chart and see if you can disable grafana

Anything else we need to know:
Related issue: helm/helm#2479
Umbrella charts: https://github.com/helm/helm/blob/master/docs/charts_tips_and_tricks.md#complex-charts-with-many-dependencies

[paskal]

I'm using prometheus-operator as a subchart of my own chart, and values are propagated properly to it. How is your scenario is different from mine? Your description (answer to what you did, and what you expect to happen) is not clear at all at current state.

[blacksails]

@paskal are you configuring any of the subcharts of prometheus-operator?

[paskal]

Yes, of course, here is my values.yaml:

prometheus-operator:
  # remove parent chart name from this one
  fullnameOverride: prometheus-operator
  fullname: prometheus-operator
  # Kube-scheduler on gke
  kubeScheduler:
    enabled: false

  # Controller Manager on gke
  kubeControllerManager:
    enabled: false

  # kubeDNS instead of coreDns on gke
  kubeDns:
    enabled: true
  coreDns:
    enabled: false

  # etcd on gke
  kubeEtcd:
    enabled: false

  grafana:
    # set label to reuse in prometheus-config
    sidecar:
      dashboards:
        label: grafana_dashboard
    # anonymous access
    grafana.ini:
      auth:
        disable_login_form: true
        disable_signout_menu: true
      auth.basic:
        enabled: false
      auth.anonymous:
        enabled: true
        org_role: Editor

[blacksails]

@paskal It might be related to me changing the boolean used as condition in requirements.yaml. I will see if I can reproduce it again on a new chart in a few minutes.

[blacksails]

I also tried to improve the issue description a little to make it more clear.

[paskal]

By the way, it's important how do you use that chart: if your version of prometheus-operator is unaltered, you should just run helm dependency update in root of your parent chart, and it will fetch prometheus-operator tar.gz to charts folder. If you have in unpacked, then you need to run same command in charts/prometheus-operator/ directory so it will fetch it's own dependencies.

[blacksails]

I just reproduced this.

I did the following:

1. created a new chart
2. added prometheus-operator in requirements.yaml
3. added value in the default values file which set prometheus-operator.grafana.enabled to false
4. ran helm template ./ | grep -A 10 'grafana.*deployment.yaml' and got generated grafana deployment yaml.

[blacksails]

I think this issue is really a matter of deciding wether or not the prometheus-operator chart should have subcharts which are able to be toggled on and off. That functionality does not work when using it in an umbrella chart.

I would argue that it shouldn't have grafana at least. For people who want an all-in-one installation, it would be better to have a separate chart for that which installed and configured both the prometheus-operator chart along with any related charts eg. grafana.

We don't run grafana along with our prometheus, and we don't want to. Therefore we cannot use prometheus-operator in our umbrella chart. We currently workaround this issue by separately installing our core umbrella chart and prometheus-operator.

[paskal]

I was able to reproduce it.
To fix the issue you need to:

1. download prometheus-operator to charts directory of your parent chart
2. issue helm dependency update command in /charts/prometheus-operator
3. change condition: grafana.enabled to condition: prometheus-operator.grafana.enabled in /charts/prometheus-operator/requirements.yaml

This will fix the problem for you, downside of that is that you need to manually do git pull to update prometheus-operator code.
I'm against excluding grafana from prometheus-operator requirements and I think what way I've mentioned is good enough if you need such setup.

[blacksails]

I dislike the idea of changing stuff in the charts folder. Then I would need to commit the hacked prometheus-operator chart to our umbrella chart.

Grafana is used for a lot more than just prometheus-operator, so to me it doesn't make sense that the prometheus-operator chart should claim ownership of configuring grafana. I understand that it is nice to be able to template out the grafana configurations based on how prometheus-operator is configured, but it is tight coupling between the two, which I personally would like to avoid.

At it's current state the prometheus-operator chart is not what it says to be. Currently it is a prometheus-operator + grafana chart.

When you run multiple kubernetes clusters it is nice to be able to access metrics across them. To me that means having 1 grafana outside the clusters and multiple prometheuses inside the clusters. That is the main reason why I dislike this hard coupling.

[vsliouniaev]

@blacksails Using your original example can you please try this:

grafana:
  enabled: false
prometheus-operator:
  grafana:
    enabled: false

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale]

This issue is being automatically closed due to inactivity.