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

Support rebuild command of the Digital Ocean provider #11

Merged
merged 1 commit into from
Jul 12, 2013

Conversation

tmatilai
Copy link
Owner

The vagrant-digitalocean plugin provides vagrant rebuild command that destroys the VM and creates it again (with the same IP).
Hook to that action, too.

The vagrant-digitalocean plugin provides `vagrant rebuild` command
that destroys the VM and creates it again (with the same IP).
Hook to that action, too.
tmatilai added a commit that referenced this pull request Jul 12, 2013
Support `rebuild` command of the Digital Ocean provider
@tmatilai tmatilai merged commit 92376ca into master Jul 12, 2013
@tmatilai tmatilai deleted the digitalocean-rebuild branch July 12, 2013 03:26
@patcon
Copy link

patcon commented Jul 12, 2013

Not sure if this approach helps:
https://github.com/schisamo/vagrant-omnibus/pull/23/files#L7R33

I guess I'm wondering if an alternative might be to persuade vagrant rebuild to be implemented in such a way that it kicked off from the Plugin::ALL_ACTIONS hook, which I believe is suppose to run for every provisioning-related action. I might be wrong on that :P

(Sorry, I forget if you were involved in that multi-issue convo)

@tmatilai
Copy link
Owner Author

@patcon thanks, I was more or less reading what was going on there. The solution is great and the similar structure is already in vagrant-cachier and in vagrant-proxyconf. The biggest difference is that I chose not to trigger the plugin on all Provision actions, as IMHO this is something related to setting up the VM instance and not related to provision. I prefer to avoid all extra delay in the feedback loop when testing Chef cookbooks. So at least for now we hook only to up, reload and rebuild commands.
Other opinions are of course welcome. =)

@patcon
Copy link

patcon commented Jul 12, 2013

👍 that makes sense. This does strike me as the same class of plugin -- as in, comparable to cachier or omnibus -- but having said that, it's almost arbitrary that they decided to attach to each provision event.

I guess the only case to be made (and I don't feel strongly about this at all) is that forcing a reload for a vagrantfile change tends to be reserved for things related to the VM environment -- ports, shared directories, networking, ami's, ram, providers -- that can't reasonably happen in provision. At least that was always how I always explained it to vagrant newbies :)

But yeah, I'm obviously fine with whatever you think makes most sense

@tmatilai
Copy link
Owner Author

Heh, I've been thinking a bit more of this after writing the previous comment. =)

vagrant-cachier only hooks to up and reload and I more or less copied the code from there. Vagrant won't touch the mounts on provision so all cachier configuration changes wouldn't even be possible with it.

But I agree that configuring the OS fits into the "provision" command. So I'm willing to change that after all.
Anyway I don't think users change the proxy configurations much but at least it helps when testing the plugin. :)

Thanks a lot again for your comments!

@patcon
Copy link

patcon commented Jul 12, 2013

No prob man, my pleasure :) I feel like I'm walking the fine line between bikeshedding and worthwhile contribution haha

@tmatilai
Copy link
Owner Author

I feel like buying you a 🍺 :D

@patcon
Copy link

patcon commented Jul 12, 2013

🍻

@tmatilai
Copy link
Owner Author

Okay, PR #12 has born.

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 this pull request may close these issues.

2 participants