Use same options in vagrant-spk as vagrant has

[JamborJan]

Is it possible to ensure that vagrant-spkunderstands by default the same arguments and options as vagrantdoes? I have many times the problem when I destroy a vagrant box that it takes forever until the process decides to force destroy the box. With vagrant I can force it right away but vagrant-spk doesn't understand that option. Would save some time as the workaround through vagrant requires me to get the box's id via vagrant global-status. Either way round I lose couple of minutes.

Thanks!

jj$ vagrant-spk halt -f
usage: /usr/local/bin/vagrant-spk [-h] [--work-directory WORK_DIRECTORY]
                                  {setupvm,up,init,dev,pack,verify,publish,halt,destroy,global-status,ssh}
                                  [command_specific_args [command_specific_args ...]]
/usr/local/bin/vagrant-spk: error: unrecognized arguments: -f

[paulproteus]

@zarvox - is it time for us to reconsider this design decision of
whitelisting parameters? Maybe for certain actions, like "halt", we allow
all extra parameters to flow through to vagrant?

I do tell people to

cd .sandstorm
vagrant provision
cd ..

with some frequency. Maybe that deserves a separate issue.

Jan - are you asking for all the same Vagrant "verbs"
(provision/up/halt/suspend/etc), or would allowing all the "-f" etc.
parameters on "vagrant-spk halt" do what you need?

[zarvox]

Hmmm. I'm not against the more general idea on principle, but we'd want to redo our argument parsing to make this work cleanly on all the commands, which is a nontrivial but not-excessive amount of work. For the specific case of halt and up and the other commands we basically directly wrap, I guess we already ignore extra arguments, so I don't think we'd regress in practice if we passed additional args through, especially if we're only doing it for the specific vagrant commands we wrap.

A catch or two: we both implement an init command, which do different things. vagrant-spk destroy already uses -f by default.

@JamborJan Note that if you want to interact with vagrant directly, you can do so by entering the .sandstorm folder and using vagrant directly from there. I'm not sure if that's more or less convenient than looking up the box id, but figured I'd let you know about the option! :)

[JamborJan]

Thanks for clarification @zarvox. As it is only a small thing, feel free to close this issue without further action if you think the current situation is good enough.

[paulproteus]

See also #145

[ocdtrekkie]

@johnbintz hit this, it seems. When I was looking at the vm subcommand code, it looked like command-specific-arguments were already passed (which is why I marked this closed), but we should fix this if vagrant-spk vm destroy -f doesn't work.