0

I have a Deployment Manager template/schema and I want to dynamically include different startup-script options for cloud-init depending on the template.yaml I am calling. In my template.jinja I have:

      metadata:
        items:
        - key: startup-script
          value: |
{{ imports['startup-script-pre']|indent(14, true) }}
{{ imports['startup-script-custom']|indent(14, true) }}
{{ imports['startup-script-post']|indent(14, true) }}

All the imports are included in the final output, however the jinja2 inside of them is not processed, it leaves things like {{ env["name"] }} in there for cloud-init to fail on. Inside the GCP console the Expanded Config looks like:

systemctl daemon-reload
systemctl enable {{ env["name"] }}
systemctl start {{ env["name"] }}

which obviously cloud-init has no idea how to deal with.

Is there a way to force those imports to be processed for jinja instead of just inserted raw?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.