Packer: amazon-chroot: .Device and .MountPath variables not available for provisioners

[mercora]

Hello folks,

i create AWS AMIs by using the amazon-chroot builder and running ansible with the chroot connection type. Packer creates the volume, attaches it, formats the disk, mounts the volume and runs debootstrap. Afterwards i use the ansible provisioner by providing a variable to let it know where it should chroot into. Ansible will setup the system accordingly which also includes installing the bootloader.

There are two limitations with this approach, that make it impossible to parallelize AMI builds:

1.: I need to specify a fixed location for the chroot in order to know in which directory ansible should run.
2.: In order to install the bootloader i need to know the device name in advance. Currently this works by assuming the first device attached is /dev/xvdf and trying to avoid parallel builds.

This is not only inconvenient; In case packer was not able to detach or unmount the volume both assumptions might not hold true anymore and further builds will fail sometimes without immediately noticing. For example, if the volume is still attached, the bootloader would be installed to the wrong volume.

If somehow possible i would highly appreciate it if there would be a way to access the .Device and .MountPath variables in the provisioners section. This would allow me to set variables for ansible to let it know what it should do exactly.

Finally this would allow to have parallel builds in this setup and make it more resilient to failure cases. If there might already be a way to do this and i did not notice please provide me a hint.

Thanks!

[rickard-von-essen]

I think you can workaround this by passing a temp file as an argument (-var info-file=$(mktemp)) and us that in pre_mount_commands to write the .Device to it. In your provisioner you can then source this to know which device you should use. (.MountPath can be derived from .Device).

[SwampDragons]

Thanks for opening this -- I'm in a broader discussion with the other Packer developers at HC right now about how to share this kind of builder-generated information gracefully with the provisioners. We've created hacky workarounds in the past (see the winrmpassword) code; but this is another example of a use case that would be solved if we find a more graceful and generalizable solution.

[mercora]

@rickard-von-essen guess that will work for me as a workaround, thanks!
@SwampDragons i would appreciate that effort. if there is something i can do to help with that let me know.

[SwampDragons]

I appreciate that :) For now, we're still in the brainstorming stage. It's a big architectural and philosophical shift.

[SwampDragons]

I'm closing this in favor of the meta-issue I've created to track these requests and the architectural rework that'll be required to allow it.

To follow that work, see #7079

[SwampDragons]

I'm reopening this issue and targeting for v1.5.1. The groundwork has been laid in 7079 but I don't have time to implement this portion until next release.

[hashibot[bot]]

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.