`vagrant up` does not initiates provisioner
mohitsethi opened this issue · 40 comments
Upgraded to Vagrant Version 1.3.5(Windows). For some reason vagrant up doesn't initiates provisioner & quits after mounting shared folder. Though vagrant provision after vagrant up does work
Log:
$ vagrant up
Bringing machine 'dev' up with 'virtualbox' provider...
[dev] Clearing any previously set forwarded ports...
[dev] Creating shared folders metadata...
[dev] Clearing any previously set network interfaces...
[dev] Preparing network interfaces based on configuration...
[dev] Forwarding ports...
[dev] -- 22 => 2222 (adapter 1)
[dev] Running 'pre-boot' VM customizations...
[dev] Booting VM...
[dev] Waiting for machine to boot. This may take a few minutes...
[dev] Machine booted and ready!
[dev] Setting hostname...
[dev] Mounting shared folders...
[dev] -- /vagrant
That is the expected behavior now. The provisioner will only run on the
first run of vagrant up and not on ones afterwards. I think if you use
"vagrant up --provision" you will get the behavior you expect.
On Oct 25, 2013 7:10 AM, "Mohit Sethi" notifications@github.com wrote:
Upgraded to Vagrant Version 1.3.5(Windows). For some reason vagrant updoesn't initiates provisioner & quits after mounting shared folder. Though vagrant
provision after vagrant up does workLog:
$ vagrant up
Bringing machine 'dev' up with 'virtualbox' provider...
[dev] Clearing any previously set forwarded ports...
[dev] Creating shared folders metadata...
[dev] Clearing any previously set network interfaces...
[dev] Preparing network interfaces based on configuration...
[dev] Forwarding ports...
[dev] -- 22 => 2222 (adapter 1)
[dev] Running 'pre-boot' VM customizations...
[dev] Booting VM...
[dev] Waiting for machine to boot. This may take a few minutes...
[dev] Machine booted and ready!
[dev] Setting hostname...
[dev] Mounting shared folders...
[dev] -- /vagrant—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2421
.
@mohitsethi as @canausa explained, thats the expected behavior since 1.3.0 so could you please confirm that the provisioner does get run on the first vagrant up after a vagrant destroy?
If it doesn't, would you mind gisting the output of running a VAGRANT_LOG=debug vagrant up right after a vagrant destroy over there so we can better understand whats going on your side? Thanks!
@canausa, realized this has changed after looking at CHANGELOG. Personally
i would like provisioner(Chef in my case) to run every time which ensure my
env is exactly what i want.
Thanks @fgrehm, provisioner run on first vagrant up.
On Fri, Oct 25, 2013 at 4:57 PM, Fabio Rehm notifications@github.comwrote:
@mohitsethi https://github.com/mohitsethi as @canausahttps://github.com/canausaexplained, thats the expected behavior since
1.3.0https://github.com/mitchellh/vagrant/blob/master/CHANGELOG.md#130-september-5-2013so could you please confirm that the provisioner does get run on the first vagrant
up after a vagrant destroy?
If it doesn't, would you mind gisting https://gist.github.com/ the
output of running a VAGRANT_LOG=debug vagrant up right after a vagrant
destroy over there so we can better understand whats going on your side?
Thanks!—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2421#issuecomment-27083132
.
Mohit Sethi*
_Twitter: @mohitsethi http://twitter.com/mohitsethi | *_Github:
mohitsethihttps://github.com/mohitsethi
*
I wouldnt close this issue since the documentation isnt updated. it says that the provisioner will run on vagrant up, vagrant reload and vagrant provision
Is there a config option to keep the old behaviour for backward compatibility?
Something like:
Vagrant::Config.run do |config|
config.vm.provision :shell, :path => "test.sh"
config.vm.provision_run :once
# :once or :always with :once being the default
end
This would give us time to update the behaviour of our provisioners gradually.
+1 for config.vm.provision_run
+1 on the :once or :always suggestion
👍 on the :once or :always config option.
+1 for the config.vm_provision_run option here as well.
If you halt a box with services running... a vagrant up will not start those services back up. You need the provisioner to start them.
I would really like to revert to the old default behavior. I.e. run provisioners always unless user explicitly specifies --no-provision. Based on the number of questions in IRC, the current functionality seem to be really confusing for many. Also personally I basically always want to provision if I spin a box up. And provisioners are supposed to be idempotent so there is no harm done running them extra times (other than the time it takes).
Just my 0,02€.
I'm open to the once/always config option.
I'm still unsure whether the old behavior was better or if only people used to the old behavior are posting here. Personally, I've very much enjoyed the new behavior.
And provisioning should always run when you create the machine ("up" from a destroy).
Idempotence is only a feature of Chef/Puppet/etc. Shell scripts you have to build it in. And for people who aren't used to provisioners (devs, not ops), idempotency is not something they know about, which caused issues with the old behavior.
How about a poll in the mailing list and IRC? I'm not trying to fight against your will, but I'm curious what's the distribution of opinions. =)
And for sure I can hack my way with shell aliases etc. That would be even easier with config option, what ever the default is. Maybe also the config.vm.provision method could take an attribute to override the provision_run option on a provisioner basis?
Then I guess someone should volunteer to implement this. ;)
I think that the new behavior make more sense. I was initially surprised that the provisioner was running at every vagrant up, and I like the idea that the provisioner should run only once. Everything else should be build or provided within the provisioner scripts.
However if you have a number of vms working with the old behavior it's hard to change all of them at once. A backward compatible option would offer the possibility of a gradual migration to those who still want to upgrade to the newest vagrant releases but without having to port all old scripts at once.
So for me is:
+1 for the new behavior
+1 for the backward compatible option.
Bruno
It could be better to specify with provision how it should be run, ie:
config.vm.provision :shell, :path => "init_env.sh", :run => 'once'
config.vm.provision :shell, :path => "update_env.sh", :run => 'always'
👍 for :once or :always config
How about also a info message when the provisioning is skipped? I think that would make it clear for many cases.
I'm happy to help implement this, but I can't promise any timeline. Too many projects, too little time. ;)
+1 for :once or :always config
or returning to the old behaviour
One more thought. If provisioner entries can be configured independently, it complicate logic in plugins that want to action only when really provisioning. For example vagrant-berkshelf is supposed to action only if there are chef provisioners that are going to be run. So this will be again a breaking change for those kind of plugins.
+1 for @tmatilai "info message when the provisioning is skipped".
+1 for :once or :always config
+1 for an :always argument.
The issue is closed. Has this been solved?
👍 for an option.
@estahn no this has not been solved. The feature request is still open.
@mohitsethi would you mind re-opening this issue for the feature request? Or, should a new issue be created with the feature request?
If there is no promise that someone will work for implementing the feature, the issue will most likely to be closed. See @mitchellh's comment on #2770.
I'd be open to this feature. I'll open it.
I'd definitely like to see this feature available.
Another 👍 for the :always option. I really need this because starting Apache using chkconfig or /etc/rc.local doesn't work, as it needs the shared folder to be mounted (some .conf files are symlinks to the shared folder). If someone knows a workaround for this until we get the :always option, I'd appreciate it.
Oh yeah, and I do feel that having provisioners run only once (by default) makes more sense. 👍
I'd also love to see this feature, with the ability to set, per-provisioner, whether it's run the first time or always.
👍 for the :once or :always configuration option. Has there been any status change on this?
If no one is working on this I could give it a try.
👍 for :always
Also 👍 for :once and :always.
I have nginx vhosts in a shared folder and nginx needs to be reloaded after the shared folder has been mounted for it to read them.
👍
Done! Vagrant 1.6 will allow you to specify: run: "once" or run: "always" on a per-provisioner basis.
Thanks Mitchell!
Nice one! Thanks Mitchell..
Great, thank you Mitchell!
Sweet, was just looking for this feature today! It's annoying to have to have to run provision everytime. Thanks Mitchell!
👍
👍