User variable not expanded in pause_before

[sulaweyo]

For a shell provisioners the option "pause_before" does not evaluate user variables. I can add a fixed value there and it works fine but as soon as i use a user variable the template can no longer be validated or built as the variable is not expanded.

version: 1.0.2 and earlier as well
OS: linux x64
Log:

ui error: Failed to parse template: 1 error(s) occurred:
* provisioner 8: 1 error(s) decoding:
* time: invalid duration {{user `pause_var`}}

I would like to use this after a windows reboot as WinRM is up before windows actually applied all updates and it would be nice to hand over the wait time as i run multiple builds via the same template but different puppet configuration. A fixed time works but means i have to wait the maximum time that is needed for any build even though the parts that would need it are not applied in this run.

[rickard-von-essen]

Slightly related to #4508.

[daxgames]

Any progress on this having the same issue.

Failed to parse template: 1 error(s) occurred:

* provisioner 2: 1 error(s) decoding:

* error decoding 'pause_before': time: invalid duration {{user `pause_before`}}

[SwampDragons]

I just took a quick look at this; it occurs because the variable pause_before needs to be used earlier in the build than we actually interpolate and read in environment variables. therefore, it's read into our mapstructure as a time.duration and never interpolated. If someone wants to take a stab at fixing it, PRs are welcome, but it's in a part of the code that'll probably be kind of unwelcoming for newer contributors. As it is, this is such a niche need that I am not going to prioritize it; in light of this, I'm going to close this ticket as wontfix. thanks.

[Linuturk]

wanted to chime in and say I would love to have this as well.

[daxgames]

This is not so niche, I don't think. Anyone using a pipeline to build images could benefit from it.

[SwampDragons]

I'm not sure I agree with that; In my experience, pause_before is generally fairly specific to the provisioner in question, which is why I don't think we've seen people asking to set it via an environment variable before. If this kind of environment-level tuning is absolutely necessary and you are pipelining images, you can always write a helper script to modify the Packer template, although I 100% understand that having to do so is annoying and not a great or satisfying answer. I can reopen this issue, but I still think it's unlikely that I'll be able to prioritize it any time soon and I've been trying to be better about closing issues that no one is going to work on for the forseeable future.

[daxgames]

There are definitly other things I need fixed first like #6162. This is a huge problem in that maybe 5% of my amazon-ebs Windows builds actually complete because most fail with a dial tcp error.

[avishnyakov]

This one could be useful in a light of regression on windows-restart in 1.3.1

Windows 2016 windows-restart provisioner not waiting for reboot after patching #6733

windows-restart detects reboots differently in 1.3.1 so (1) downgrading to early packer version or (2) updating all packer templates is a way forward. Having a variable to tweak pause_before timeout on the fly per build might be helpful - would help to be on the latest packer plus no template changes in needed.

Whole pause_before is useful for debugging purposed too. Ideally, separate vagrant/kitchen file would be used to spin testing env. Sometimes ad-hoc troubleshooting requires packer build to stick around and setting pause_before to 60m is a way forward. Having interpolation would enable either no wait or 60-120m so troubleshooting can be done without template modifications.

Finally, windows-restart should handle things correctly, but sometimes WinRM is up faster than windows applied/configured changes, agains tweaking pause_before might be more rock-solid and therefore having interpolation can help.

Just 2cents, of course.

[SwampDragons]

Thanks for your input. Like I said before, I can see why some people might want this, but there are workarounds for the situations you described; for example, the windows-restart provisioner has a configurable option where you can provide your own check that makes sure the system is in a state you expect before running the next provisioner.

Obviously this requires the provisioner to be working and I'm sorry for that regression. We'll be releasing the patch with the fix pretty soon.

As for this feature request, PRs are welcome but the core team won't be working on it.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.