Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hostmanager should run before provisioning #73

Closed
emilio-simoes opened this issue Feb 14, 2014 · 15 comments
Closed

hostmanager should run before provisioning #73

emilio-simoes opened this issue Feb 14, 2014 · 15 comments

Comments

@emilio-simoes
Copy link

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

@pbitty
Copy link
Contributor

pbitty commented Feb 28, 2014

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 :hostmanager

By putting this before any other provision configs, hostmanager will before the other provisioners.

@smdahlen
Copy link
Contributor

@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).

@emilio-simoes
Copy link
Author

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

@dancras
Copy link

dancras commented Mar 24, 2014

👍 Found this quite unintuitive today

@bunchc
Copy link

bunchc commented Mar 27, 2014

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)

@pbitty
Copy link
Contributor

pbitty commented Mar 27, 2014

@bunchc, can you elaborate on that? I am not sure what you mean by "push
that box's info".

@bunchc
Copy link

bunchc commented Mar 27, 2014

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

@bunchc
Copy link

bunchc commented Mar 27, 2014

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.

@bunchc
Copy link

bunchc commented Mar 27, 2014

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.

@pbitty
Copy link
Contributor

pbitty commented Mar 29, 2014

@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?

@bunchc
Copy link

bunchc commented Mar 29, 2014

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

@pbitty
Copy link
Contributor

pbitty commented Mar 29, 2014

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?

@bunchc
Copy link

bunchc commented Mar 29, 2014

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

@bunchc
Copy link

bunchc commented Apr 9, 2014

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.

@bunchc
Copy link

bunchc commented Apr 14, 2014

I think #88 fixes this. Mind checking / merging?

@pbitty pbitty closed this as completed in 4024856 May 25, 2014
pbitty added a commit that referenced this issue May 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants