aws-samples / eks-blueprints-add-ons

MIT No Attribution
139 stars 763 forks source link

[Bug] The destination namespaces in some of these examples do not respect the namespace defined in Terraform #43

Closed spkane closed 1 year ago

spkane commented 2 years ago

Originally reported here: https://github.com/aws-ia/terraform-aws-eks-blueprints/issues/498

I had this setup in my code when I was testing it:

  enable_prometheus                   = true
  prometheus_helm_config = {
    version          = "15.8.5"
    create_namespace = true
    namespace        = "monitoring"
    values           = [templatefile("${path.module}/helm_values/prometheus-values.yaml.tftpl", {nodeSelector = local.primaryNodeSelector})]
  }

The values template looks like this:

# See:
# https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus/values.yaml
#
# This is a template, so we can get values from terraform.
#

alertmanager:
  nodeSelector: ${jsonencode({ for ns_key, ns_value in nodeSelector : ns_key => ns_value })}

server:
  nodeSelector: ${jsonencode({ for ns_key, ns_value in nodeSelector : ns_key => ns_value })}
  retention: 1h

  resources:
    requests:
      cpu: 500m
      memory: 512Mi

  global:
    scrape_interval: 15s

pushgateway:
  nodeSelector: ${jsonencode({ for ns_key, ns_value in nodeSelector : ns_key => ns_value })}

It looks like the monitoring namespace is created, but the ArgoCD application/helm is not targeting the right namespace.

CleanShot 2022-05-13 at 08 27 07

So, looking at the line here:

https://github.com/aws-samples/eks-blueprints-add-ons/blob/main/chart/templates/prometheus.yaml#L33

It looks like the destination namespace is hard-coded (and maybe in other examples) and does not respect what was set in the Terraform code

vara-bonthu commented 2 years ago

Good spot @spkane I can see all the templates are hardcoded with namespace in eks-blueprints-add-ons repo. I think we need to pass the namespace as well to these templates from Blueprints repo.