search

hashicorp / vagrant

Vagrant is a tool for building and distributing development environments.
https://www.vagrantup.com
Other
26.27k stars 4.43k forks source link

Behaviour of 'vagrant up' has changed #78

Closed jeroenvandijk closed 14 years ago

jeroenvandijk commented 14 years ago

I think this happens after 3.3 but i could be wrong.

I've tried edge (383dfbce09cfcc2dba8b3d436e0afaff6c358671) and I see that vagrant up always does provisioning, not just the first time.

Since there is no other command to start a box this is inconvenient.

Jeroen

mitchellh commented 14 years ago

What do you mean by "always does provisioning?" The provisioners should also run during an up, so so far this sounds like expected behavior (since if no changes occured, chef will just exit).

What is the behavior you would like and in what situation?

jeroenvandijk commented 14 years ago

Sorry I'll explain a bit more.

I have been used to and have been observing the following behaviour up until 3.3: vagrant up => "starts VM if not started yet, and provisions when box didn't exists before" vagrant reload => "restarts VM, and always provisions box"

I know that chef will just exist after it has done all checks, but those checks can take long enough to annoy when unnecessary (in my case that's for rails_test_box). And sometimes you just want to start the box and don't care about the provisioning.

So what I would like to see is a command that just starts the box without provisioning.

mitchellh commented 14 years ago

jeroen,

Ah I see what you're saying. I do see that there is a gap in the commands where there is no "start but don't do anything other than start it" type of command. And vagrant reload kind of forces the provision so perhaps the semantics of up should be changed such that it only provisions if its creating the VM for the first time.

Another idea which was proposed in IRC was to add a --no-provisioning flag to vagrant up.

I've been trying to think what the expected behavior of the command should be, and I'm currently leaning towards the expected behavior being to run the provisioner, and that I should go with the flag, but I wanted to get your opinion first.

What do you think?

Mitchell

mitchellh commented 14 years ago

jeroen,

Actually, I posted too early. Especially with the new vagrant provision command, perhaps the semantics that you propose for up do make more sense. I'll continue to think on this and will probably take action on this issue within the next couple days.

Mitchell

jeroenvandijk commented 14 years ago

Hi Mitchell,

I think either way is good, as long as there is a known option. I tend to provision a box once in a while. Mostly once a box has been fully provisioned, I'm just using the box with vagrant halt to stop it and vagrant up to start it again, no need for provisioning here. So I think vagrant up without provisioning (except for a fresh box) suits my needs the best.

I guess it all depends on what the common vagrant workflow is. What is your preferred way?

Jeroen

mitchellh commented 14 years ago

Changed semantics of 'up.' 'up' will now only provision when the VM is being created from scratch. Otherwise, it simply starts the VM. [closed by b9498611864650f087c772641e00a67b1511d8ea]