Packer: templating meta issue

Created on 10 Feb 2017  路  3Comments  路  Source: hashicorp/packer

Issues about wanting some kind of templating are opened frequently. This would be replacing variables inside static files with information from packer either during the file provisioner or inside floppy_files or the http_server

Here are some examples:

I don't believe packer should be in the business of providing templating, as it's out of scope of packer in my opinion. However, it does seem to be requested often.

I'd like to discuss here possible solutions, but right now I don't have any.

enhancement hcl2 post-1.0 thinking

Most helpful comment

Some usecases to consider. Right now, I have a colleague who made a JS program to generate all of his packer configs, but the logic in that JS script is fairly straight-forward, and would be nice to simply keep all of that in one place. He also needs a separate JS script for each target json file, which is a maintenance headache.

I find myself in situations where my json file could benefit from comments so that others can understand it better. Another thing I find myself doing is copying-n-pasting file upload provisioner entries which could easily be solved with a jinja for-loop construct.

A possible problem with jinja2 templating of JSON files is the trailing comma problem with JSON. The templating would have to be smart enough to know whether or not a comma is needed (perhaps it would make sense to switch to YAML?).

All 3 comments

if packer was written in python, the answer would be to use jinja2, which is an extremely powerful and easy-to-use templating language. Looks like someone tried a go port of it a couple years ago: https://github.com/jmoiron/jigo

Some usecases to consider. Right now, I have a colleague who made a JS program to generate all of his packer configs, but the logic in that JS script is fairly straight-forward, and would be nice to simply keep all of that in one place. He also needs a separate JS script for each target json file, which is a maintenance headache.

I find myself in situations where my json file could benefit from comments so that others can understand it better. Another thing I find myself doing is copying-n-pasting file upload provisioner entries which could easily be solved with a jinja for-loop construct.

A possible problem with jinja2 templating of JSON files is the trailing comma problem with JSON. The templating would have to be smart enough to know whether or not a comma is needed (perhaps it would make sense to switch to YAML?).

Another use case: passing packer variables (like builder_type, ...) to scripts in autounattend (windows) or kickstart/preseed (linux).

E.g.: vsphere-iso builder uses vmware tools to get IP and go next "Waiting for IP" step. Having builder_type variable (or something like provisioning phase PACKER_BUILDER_TYPE env variable) allow to use more generic script switching to step installing vmware tools at build time, avoiding code duplication.

I think having variables at earlier stages allow more flexibility and DRY code.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Nikoos picture Nikoos  路  3Comments

frezbo picture frezbo  路  3Comments

shantanugadgil picture shantanugadgil  路  3Comments

Tensho picture Tensho  路  3Comments

sourav82 picture sourav82  路  3Comments