hostmanager should run before provisioning
emilio-simoes opened this issue · 15 comments
hostmanager should run before provision. Some times, when running a provisioner like chef or puppet, is necessary that the VM can find themselves by the hostname. Running the hostname after provision does not allow to use this plugins in that situations
I think this would make sense. @smdahlen, what do you think?
@emilio-simoes, for now, you can tell hostmanager to run as a provisioner like so:
config.vm.provision :hostmanagerBy putting this before any other provision configs, hostmanager will before the other provisioners.
@pbitty I think in theory it is fine. I'm not sure if you can guarantee it at the plugin level -- its been a while since I've wrapped my head around it though. You are correct that the user can specify ordering of provisioners in a Vagrantfile though (which is typical).
@pbitty thanks for the tips, that does the trick.
Still it would be nice, if possible of course, that the plugin would execute before the provisioning.
👍 Found this quite unintuitive today
Using it as a provisioner helps, but doesn't seem to push that box's info back out at the same time, thus causing some chicken-egg issues (e.g. having chef-server come up last and using knife-bootstrap)
@bunchc, can you elaborate on that? I am not sure what you mean by "push
that box's info".
More specifically, I have the following setup:
https://gist.github.com/bunchc/9807137
When it gets to the knife bootstrap line, the remote hosts in which it is running knife-bootstrap don't know who the chef-server is, which, should have been pushed out by running the provisioner:
ERROR: Error connecting to https://rpcs-chef-01.cook.book/clients - getaddrinfo: Name or service not known
To be clear, the other nodes have come online first, the chef-server can reach them just fine (thanks to host-manager) but not the other way around, even after having used the provisioner
It looks like this from command.rb:
# update /etc/hosts file for specified guest machines
with_target_vms(argv, options) do |machine|
@env.action_runner.run(Action.update_guest, {
:machine => machine,
:provider => options[:provider]
})
end
Isn't getting called when run as a provisioner.
Ok, so after a few hours of fighting with rbenv and ffi, I can't seem to get bundler to be happy enough to let me test fixes. I think that's what it is above however.
@bunchc The code in command.rb runs when you call vagrant hostmanager from the command-line. It is it not supposed to run during provisioning.
If I understand correctly, you need to have the chef-server booted up before the other machines? If that is the case, you should be able to do that by defining the chef-server in your Vagrantfile.
Is that the issue, or am I missing something?
@pbitty Say I've 2 machines: (m1 & m2 respectively).
When M1 boots, all is good.
When M2 boots, hostmanager (via box.vm.provisioner :hostmanager) tells him where M1 is. We're still kinda good.
However, before M2 is done provisioning, M1 needs to communicate with M2 by name. Despite having called the provisioner, M2's info has not yet reached M1.
My desired outcome, is when calling hostmanager as a provisioner, it updates all nodes instead of just pulling the values in locally.
Ahh, I get it now. :) (To make it more confusing, in my response I meant
to write _"...defining the chef-server _first* in your Vagrantfile..."*,
but that is irrelevant reading your explanation.)
I can see now, provisioner.rb
only updates the machine being provisioned.
I think we could make things more consistent by fixing the main issue here,
which is that the regular hostmanager hook only runs at the end of
everything, after provisioning.
The default behavior is to always update every machine that is running. If
we fix the hook ordering it seems that it will also solve your problem and
you won't need to use it as a provisioner anymore.
What do you think?
Both solutions would work. I think ideally, I'd have the behavior be consistent when called as a provisioner as well as when the hook to host manager runs. For my specific use case, if you make the fix as described, it will solve my issue (and it looks like that of the other commenter as well).
So, I think it has something to do with the action_hooks in plugin.rb, however, I'm not the best at this, and can't seem to make them work for anything other than how they are set now. They should be set to:
hook.before Vagrant::Action::Builtin::Provision, Action.update_all
or something like that.