Fixed issue with deployment template

[xogoodnow]

The current template does not render extra volumes properly with the given values

here is the section for values.yaml

  # -- Extra Volumes for the pod
  extraVolumes:
    - name: network-alerts
      configMap:
        name: network-alerts

        
  # -- Extra Volume Mounts for the container
  extraVolumeMounts:
    - name: network-alerts
      mountPath: /rules/network-rules.yaml
      subPath: network-rules.yaml

here is the rendered manifest in the previous template:

          volumeMounts:
            - name: alerts-config
              mountPath: /config
            - mountPath: /config/network-rules.yaml
              name: network-rules
            
      volumes:
        - name: alerts-config
          configMap:
            name: vmalert-stage-victoria-metrics-alert-server-alert-rules-config
        - configMap:
          - name: network-rules.yaml
          name: network-rules

here is the rendered version in the corrected template:

            - name: network-rules
              mountPath: /config/network-rules.yaml
              subPath: network-rules.yaml
            
      volumes:
        - name: alerts-config
          configMap:
            name: vmalert-stage-victoria-metrics-alert-server-alert-rules-config
        - name: network-rules
          configMap: 
            name: network-rules.yaml
            

[AndrewChubatiuk]

hey @xogoodnow
cannot reproduce an issue you're having, your fix limits using server.extraVolumes for configMaps only
also please mention in an issue a chart version you are using

[xogoodnow]

Hi @AndrewChubatiuk,

on version: 0.12.5

just re created the issue to be sure:

steps I took:
after I pulled the lates
just uncomment the following:

  # -- Extra Volumes for the pod
  extraVolumes:
    - name: example
      configMap:
        name: example

  # -- Extra Volume Mounts for the container
  extraVolumeMounts:
     - name: example
       mountPath: /example

ps: obviously I had to add a datasource and an alert to the values.yaml

then render the template

helm template vmalert victoria-metrics-alert/ -n monitoring --dry-run

here is the result:

          volumeMounts:
            - name: alerts-config
              mountPath: /config
            - mountPath: /example
              name: example
            
      volumes:
        - name: alerts-config
          configMap:
            name: vmalert-victoria-metrics-alert-server-alert-rules-config
        - configMap:
            name: example
          name: example

as you can see the volumes and volumeMounts section are wrong.

Cheers

[AndrewChubatiuk]

what's wrong in this result?

volumeMounts:
            - name: alerts-config
              mountPath: /config
            - mountPath: /example
              name: example
            
volumes:
        - name: alerts-config
          configMap:
            name: vmalert-victoria-metrics-alert-server-alert-rules-config
        - configMap:
            name: example
          name: example

[xogoodnow]

Here is the first volumeMounts:

the second volumeMounts is:

they are rendered in reverse order
the same issue goes for volumes section

[xogoodnow]

This results the deployment to be stuck in "in progress" state and the relatives pods would be stuck in "creating container" status.

[AndrewChubatiuk]

they are rendered in reverse order

order makes no difference

[AndrewChubatiuk]

This results the deployment to be stuck in "in progress" state and the relatives pods would be stuck in "creating container" status.

have you checked kubectl events for more information?

[xogoodnow]

The parameters "- configMap" or "-mountPath" have no meaning in a k8s manifest. so when it is applied and sent to API server it does not know what to do with it and it just gets stuck.

I think you did not understand my point.

The first one is "-name" and then comes the "- mountPath"
but with the extra volume first comes the "-mountPath" and then "-name" which is meaningless.

[xogoodnow]

This is wrong:

          volumeMounts:
            - name: alerts-config
              mountPath: /config
            - mountPath: /example
              name: example
            
      volumes:
        - name: alerts-config
          configMap:
            name: vmalert-victoria-metrics-alert-server-alert-rules-config
        - configMap:
            name: example
          name: example
          

This is correct:

          volumeMounts:
            - name: alerts-config
              mountPath: /config
            - name: example
              mountPath: /example
            
      volumes:
        - name: alerts-config
          configMap:
            name: vmalert-victoria-metrics-alert-server-alert-rules-config
        - name: example
            configMap:
          name: example

[AndrewChubatiuk]

both

configMap:
  name: example
name: example

and

name: example
configMap:
  name: example

produce the same map, order is not important

[xogoodnow]

I ran the test without any pipelines and in fact you are right.
so the issue is not with functionality.
But manifest linters can not accept this and they keep on failing.

1. Thank you for pointing this out
2. Why not change the template so even at them time of rendering, the parameters would be in correct order?

[AndrewChubatiuk]

2. adding ordered rendering requires to cover all possible cases and also to move it to common chart and reuse it everywhere