Is it possible to retain key order in an object?

[netthier]

I'm defining and using some objects in two separate places:

# deployment.yaml
deployments:
  - path: deployment
    vars:
      - file: "config.yaml"

# config.yaml
config:
  env:
    user: foo
    password: hunter2
    connection_template: "$(user):$(password)@host"

# deployment/pod.yaml
# [snip]
env:
{% for name, val in config.env.items() %}
  - name: "{{ name }}"
    value: "{{ val }}"
{% endfor %}

The issue now is that the loop in the last code example sorts the keys alphabetically:

# templated pod.yaml
env:
  - name: "connection_template"
    value: "$(user):$(password)@host"
  - name: "password"
    value: "hunter2"
  - name: "user"
    value: "foo"

This breaks Kubernetes environment variable substitution, which requires the to-be-substituted variables to be defined before the template.
Is there some way around this short of using something like _user and _password for the variables that need to come before the template? Turns out _ gets sorted after everything else, so i prefixed everything with A_ in the meantime which clearly is suboptimal

[codablock]

The libraries Kluctl uses internally do not support this and they explicitly sort keys alphanumerically. I actually prefer this as it allows consistent compression, diffing and patching (which will get more important in future versions of Kluctl due to new features).

Your specific use case is however of an example where a list in config.yaml would have been the better choice as it would make the order very explicit. Example:

# config.yaml
config:
  env:
    - name: user
      value: foo
    - name: password
      value: hunter2
    - name: connection_template
      value: "$(user):$(password)@host"

# deployment/pod.yaml
# [snip]
env:
{% for e in config.env %}
  - name: "{{ e.name }}"
    value: "{{ e.value }}"
{% endfor %}

Or, in case you know that the provided list is the only source of env vars:

# deployment/pod.yaml
# [snip]
env: {{ config.env | to_json }}

The above is a matter of taste...I prefer it in most cases as it's short and requires less templating. Check this to understand why to_json works here. to_yaml could also be used but it would also require you to handle indention as well.

[netthier]

Thanks for the answer, makes sense.
I wanted to use name: value syntax directly as I had a lot of env variables to set and wanted it to stay readable.
I'll have to think more about it.