Vagrant: Incorrect minion_id for salt provisioner

[xuhcc]

• Vagrant version: 1.8.3, 1.8.4
• Host operating system: Arch Linux
• Guest operating system: Debian Jessie

Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "debian/contrib-jessie64"
  config.vm.hostname = "test-vm"
  config.vm.synced_folder "vagrant/salt/roots/salt/", "/srv/salt/"
  config.vm.provision :salt do |salt|
    salt.masterless = true
    salt.minion_id = "test-vm"
    salt.minion_config = "vagrant/salt/minion.conf"
    salt.run_highstate = true
    salt.verbose = true
  end
end

Vagrant ignores both vm.hostname and salt.minion_id settings:

vagrant@test-vm:~$ cat /etc/salt/minion_id 
debiancontrib-jessie.vagrantup.com

As a result, highstate execution fails: No Top file or external nodes data matches found

[BrighTide]

I was having this problem too, the following config ended up working for me after I did a 'vagrant destroy'

config.vm.network "private_network", type: "dhcp"
config.vm.hostname = "test"   
...

salt.minion_config = "minion"
salt.minion_id = "test"
salt.verbose = true
salt.run_highstate = true # Executes state.highstate on vagrant up

and in minion config

file_client: local
...

could be related to whatever problem this guy was having https://groups.google.com/forum/#!topic/salt-users/Tl_s2cfLgrk

[xuhcc]

I switched back to 1.8.1 until this bug is fixed.

[xuhcc]

This works with vagrant 1.8.5:

Vagrant.configure("2") do |config|
  ...
  config.vm.hostname = "test-vm"

  # Fix salt minion ID
  config.vm.provision "shell" do |sh|
    sh.inline = "mkdir /etc/salt && echo $1 > /etc/salt/minion_id"
    sh.args = [config.vm.hostname]
  end

  # Then do normal salt provisioning
  config.vm.provision :salt do |salt|
    ...
  end
end

[nicksloan]

I believe what is happening is that the vm.hostname setting is being applied AFTER the salt provisioner is installed. salt-minion caches the minion ID on first run (otherwise, it would be annoying for it to change periodically). It seems that a recent release of vagrant changed the order in which these items occur.

[nicksloan]

Never mind. I was super wrong about that.

[ssplatt]

hitting this on 1.8.5, too. I have a multi-machine setup where 3 out of 5 get the minion id set correctly. I tried to simplify it down to single machine test vagrantfile and that never gets the minion id set correctly. socket.getfqdn() inside the vm returns the correct hostname, as does hostname -f.

adding in salt.bootstrap_options = "-i #{hostname}" does work.

[brianholland99]

I was having a similar issue with a configuration that did not use masterless, so does not totally match the original issue and in my example, hostname is used as minion_id. I may have misread the patch that was linked above, but it appeared to me that it would only affect masterless configs (the original issue). I have not tried to actually test with this branch yet, but I suspect that it would not affect this example. If I get time, I will look at the code and try to determine my path through the code.

If this should be a separate issue (or I am using it wrong), let me know.

My specifics:
Ubuntu 16.04 host - Real master - The "vm.hostname" setting appears to be used for both /etc/hosts and /etc/salt/minion_id (I.e., in this case "minion01") . The salt.minion_id setting of "footest" does not appear anywhere in the /etc/salt tree on the minion.

A stripped-down Vagrantfile that produces the issue.:

Vagrant.configure(2) do |config|

  config.vm.box = "../vagrant-centos-7.2-minimal.box"
  config.vm.hostname = "minion01"
  config.vm.provision :salt do |salt|
    salt.minion_id = "footest"
    salt.install_type = "stable"
  end
end

(Edit - Further stripped down originally posted Vagrantfile.)

[brianholland99]

I read the commit message on the patch. It did question whether the get_masterless was the proper abstraction. A slight change might work by pulling the setting of minion_id outside of check "if @config.masterless", assuming the variable being set is used in the case of a real master. The posted examples of the issue seemed to be using masterless. Mine does not, so it probably just needs to be done globally as minion_id should be relevant for all cases.

[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.