If you define a minion_config_file, the step that moves directories uploaded via the local_state_tree and local_pillar_roots variables to their final destinations, remote_state_tree and remote_pillar_roots, respectively, does not perform the copy. This is due the final values of remote_state_tree and remote_pillar_roots being empty once the run starts.
0.11.2
resource "aws_instance" "test" {
ami = "${module.ami.base_image}"
instance_type = "t2.micro"
subnet_id = "${aws_default_subnet.main.id}"
associate_public_ip_address = true
key_name = "yubi"
vpc_security_group_ids = [
"${module.sg.ssh}",
"${module.sg.http}",
"${module.sg.ssl}"
]
provisioner "file" {
source = "./pillar"
destination = "/tmp/pillar"
connection {
user = "admin"
agent = true
}
}
provisioner "salt-masterless" {
local_state_tree = "../salt/states"
local_pillar_roots = "../salt/pillar"
minion_config_file = "minion"
connection {
user = "admin"
agent = true
}
}
}
aws_instance.test (salt-masterless): * INFO: Salt installed!
aws_instance.test (salt-masterless): Creating remote temporary directory: /tmp/salt
aws_instance.test (salt-masterless): Creating directory: /tmp/salt
aws_instance.test (salt-masterless): Uploading minion config: minion
aws_instance.test (salt-masterless): Make sure directory /etc/salt exists
aws_instance.test (salt-masterless): Creating directory: /etc/salt
aws_instance.test (salt-masterless): Moving /tmp/salt/minion to /etc/salt/minion
aws_instance.test (salt-masterless): Uploading local state tree: ../salt/states
aws_instance.test (salt-masterless): Creating directory: /tmp/salt/states
aws_instance.test (salt-masterless): Removing directory: /srv/salt
aws_instance.test (salt-masterless): Moving /tmp/salt/states to /srv/salt
aws_instance.test (salt-masterless): Uploading local pillar roots: ../salt/pillar
aws_instance.test (salt-masterless): Creating directory: /tmp/salt/pillar
aws_instance.test: Still creating... (1m10s elapsed)
aws_instance.test (salt-masterless): Removing directory: /srv/pillar
aws_instance.test (salt-masterless): **Moving /tmp/salt/pillar to /srv/pillar**

Arrows point to where the directories are missing.
With the configuration above (assuming you've configured your provider),
local_state_tree and local_pillar_roots variables that exists.minion_config_file variable that exists.terraform applyThe docs state that you cannot use minion_config_file with defining either remote_pillar_roots or remote_state_tree. Given none of the remote_* variables are defined in the configuration above, that caveat does not apply to this issue.
I've just experienced the same issue.
* null_resource.bootstrap_nodes[1]: Unable to move /tmp/salt/states to : error executing "sudo mv /tmp/salt/states ": Process exited with status 1
Workarround is not possible as we can't provide remote_state_tree:
Error: null_resource.bootstrap_nodes: remote_state_tree and remote_pillar_roots only apply when minion_config_file is not used
Do you know when this can be fixed?
If you define the arguments remote_pillar_roots and remote_state_tree in your provisioner "salt-masterless" {} block, you will not encounter this error. It seems as if there is not an actual default set for these two arguments as noted in the documentation. Perhaps until the provisioner is updated to provide default directory locations, the documentation can be updated to reflect the actual behavior.
I submitted a PR, which I think will solve the issue of no defined defaults as indicated in the documentation: https://github.com/hashicorp/terraform/pull/19712
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.
Most helpful comment
If you define the arguments
remote_pillar_rootsandremote_state_treein yourprovisioner "salt-masterless" {}block, you will not encounter this error. It seems as if there is not an actual default set for these two arguments as noted in the documentation. Perhaps until the provisioner is updated to provide default directory locations, the documentation can be updated to reflect the actual behavior.