Adding a setting in the Vagrantfile to disable a box

[ra...@future500.nl]

[ I apologise for this issue I posted to the github repo (https://github.com/mitchellh/vagrant/issues/2983), when it's just a question and not a bug ]

Hi all,

I'd like to add two boxes called primary and secondary to a Vagrantfile, but only startup primary when I run

vagrant up

Starting the secondary box would require an explicit

vagrant up secondary

Is this possible?

I've added primary: true to the primary box, but there doesn't seem to be a way to avoid the secondary box from starting up.

(a little background: I have a project containing a development box that everyone should use to work with the project, but I also add a "production-test" box to test provisioning and deployment Ansible scripts agains a box set up like a production server. This "production-test" box is overhead for regular developers)

Regards,

Ramon de la Fuente
@f_u_e_n_t_e

[Matt Palmer]

On Mon, Feb 17, 2014 at 12:37:15AM -0800, ra...@future500.nl wrote:
> I'd like to add two boxes called *primary* and *secondary* to a
> Vagrantfile, but only startup *primary* when I run
>
> vagrant up
>
> Starting the *secondary* box would require an explicit

>
> vagrant up secondary
>
> Is this possible?

It doesn't look like it's a *supported* configuration, but if you wanted to
go all uber-monkey-patch you could rip the VMs you didn't want to start
out of the @__defined_vm_keys array inside your VM config. I would imagine
(but haven't tested) that something like:

config.vm.instance_variable_get(:@__defined_vm_keys).delete(:secondary)

would do the trick.

Patching Vagrant to support this functionality properly doesn't look like it
would be ridiculously difficult. Support an :autostart => false option to
define, add VMs to a new "autostart" array, and use *that* to determine what
to start instead of defined_vm_keys if no VM(s) are listed on the `vagrant
up` command line. I'll leave that as an exercise for the reader (become
famous, submit a patch to Vagrant today!)

- Matt

--
If you are a trauma surgeon and someone dies on your table, [...] everyone
would know you "did your best". When someone does something truly stupid
with their system and it dies and you can't resuscitate it, you must be
incompetent or an idiot. -- Julian Macassey, in the Monastery

[ra...@future500.nl]

I would love to send that very pull request - but my ruby is well... non-existant really. All PHP and no time to play... 

Anyone here with *a lot* of patience to help me muddle through this patch?

[Alvaro Miranda Aguilera]

My suggestion will be, in the vagrant file, around the secondary machine write this:

  if ENV["secondary"]
  <BLOCK FOR SECONDARY BOX>
  end


so you can then do


secondary=true vagrant up secondary

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ramon de la Fuente]

Thanks for this solution!

While this works, it also has the effect of not “seeing” the vm in commands like “vagrant status” without adding "secondary=true" (although I know I can set an environment variable).

I’d still be willing to put in the time for a proper “autostart” flag if this is more than just an edge case I dreamt up.


Ramon

> You received this message because you are subscribed to a topic in the Google Groups "Vagrant" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/vagrant-up/rwhBN4nJn4k/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to vagrant-up+...@googlegroups.com.

[Matt Palmer]

On Tue, Feb 18, 2014 at 09:33:39AM +0100, Ramon de la Fuente wrote:
> I'd still be willing to put in the time for a proper "autostart" flag if
> this is more than just an edge case I dreamt up.

I don't think it's an edge case at all. For me, Vagrant's core use case is
being able to ship a single file in any code repo that provides my team with
everything they need to work on that codebase. It's a fairly common
requirement that there will be parts of that infrastructure that don't need
to be up all the time, but would be useful in certain circumstances.

In fact, I would have expected just such a feature to already be present,
and I went source diving to learn what it was for my own future use. I was
rather surprised to discover that it didn't exist.

- Matt

--
"Mr... Baggins. It seems you have been leading... two lives. In one... you are
an ordinary hobbit... you organize your uncle's diary... give generous gifts to
children. In the other... you are the Ring Bearer... charged to carry the One
Ring to Mount Doom. One life has... a future, Mr... Baggins, and the other..."

[Alvaro Miranda Aguilera]

other option will be check for a file, if the file exists, then enable the secondary box

so where you need the secondary box, you can create a file

say  touch secondary.true

:D

secondary_box = "secondary.true"

File.exist?(secondary_box)

      <code block>

end

[ra...@future500.nl]

Ok, so I've got the source - but before I begin my first problem already arises.. 

I ran the tests and one of them failed:

Failures:

  1) Vagrant::Environment#home_path throws an exception if inaccessible

     Failure/Error: expect {
       expected Vagrant::Errors::HomeDirectoryNotAccessible but nothing was raised
     # ./test/unit/vagrant/environment_test.rb:47:in `block (3 levels) in <top (required)>'

As far as I can tell, the test tries to set the active folder to "/", assuming it is inaccessible and expecting failure - but in my case it is writeable.

(I work on OSX 10.9.1, I have not - as far as I know - changed any of the privileges on /). 

After running the tests I can confirm the following files are created in the root of my system:

-rw-r--r--   1 fzz   admin        3 Feb 24 23:12 setup_version
drwxr-xr-x   2 fzz   admin      102 Feb 24 23:12 rgloader
-rw-------   1 fzz   admin     1675 Feb 24 23:12 insecure_private_key
drwxr-xr-x   2 fzz   admin       68 Feb 24 23:12 gems
drwxr-xr-x   2 fzz   admin       68 Feb 24 23:12 data
drwxr-xr-x   2 fzz   admin       68 Feb 24 23:12 boxes

It it reasonable to expect running a test on my system *not* to create stuff it does not delete?

Anyone else see this happening?

Kind regards,

Ramon de la Fuente

@F_U_E_N_T_E

[ra...@future500.nl]

Hey all,

It took me long enough, but I managed to put in (at least some of) the work for the autostart flag here:

https://github.com/mitchellh/vagrant/pull/3058

If anyone cares to help out... that would be appreciated. 

Kind regards,

Ramon de la Fuente

On Monday, February 17, 2014 9:37:15 AM UTC+1, ra...@future500.nl wrote: