Closed philipnorton42 closed 10 years ago
Pull request #40 ( 40!!! :D ) adds the above discussed changes.
One very minor concern here is that out of the box, the provider VM name will be "vlad_vlad" because the boxname defaults to "vlad". Hardly the end of the world but while testing I switched my boxname to "vladbox" - perhaps we should consider an alternative default? I'm easy...
Original Comment By: Dan Bohea
The plot thickens...
Turns out there's actually a distinct difference between the name Vagrant associates with a box (stdout and logs) and what name the provider associates (what shows up in the list in the VirtualBox GUI).
Long story short, we'll end up using both option 1 _vlad_boxname_loadsanumbers (Vagrant) and option 2 _boxnamevlad (VirtualBox) and you'll see one or the other depending on where you're looking. Also, it sounds like UUIDs are mapped to each box and so it doesn't technically matter if duplicate box names occur in the VirtualBox GUI list (it'll just be a bugger to read).
Much of my reference is coming from here if you're interested: http://stackoverflow.com/questions/17845637/vagrant-default-name
PR to follow...
Original Comment By: Dan Bohea
Sounds like you are making some progress :)
My vote would be for 2) boxname_vlad. Especially as this already has a variable that makes sense.
This shows that it is a Vlad provisioned box, but also allows people to easily scan over the names and see the project that the box is connected to.
Original Comment By: Philip Norton
Ok, I have this working and we have options :)
1) Go with something similar to what we had before. e.g: _vlad_boxname_loadsanumbers
2) Opt for even more control over the name. There's all sorts up for grabs here including:
I'm leaning towards _boxnamevlad from the above list of example.
I wonder about how unique these names have to be and whether we should include an "initialised" timestamp to help with this and double up as a reminder for when the box was originally built (will need to figure out how to get a timestamp in Ruby). It may be that VirtualBox doesn't care if the name isn't unique (I'd better do some tests).
3) We add a parameter to settings.yml and let people set their own VM name.
4) We add the parameter as per (3) and if people leave it empty it defaults to one of the above options.
Choices, choices... I'd be interested to hear some other opinions.
Original Comment By: Dan Bohea
Right-o, that helps answer the why part then. If it's alright with you I may see about getting this part working again and submit a PR if I have any luck. I have a couple leads already.
Original Comment By: Dan Bohea
Hi Dan,
Yes, this was me. At least partly. The latest version of Vagrant changed a couple of very minor things in the configuration file, and for some reason this caused the vagrant-triggers to stop working.
The solution (after spending hours going through everything line by line and seeing what caused the error as no errors were being generated) was to remove the box name directive. Which looked like this.
#!ruby
# Set machine name.
config.vm.define :vlad do |t|
end
To be honest, I'm not entirely sure what this did, but the builds started working correctly again after removing it and the only thing that didn't work was the vlad_vlad_number in virtual box thing. I decided to leave it like this as the box name still contained 'vlad' so it wasn't much of a backwards step in functionality :)
Original Comment By: Philip Norton
I recently recreated a bunch of boxes. Said boxes used to be named in part using the "boxname" variable from Vlad's settings.yml file. On recreating these boxes it's now pretty tricky to differentiate between them (e.g. when looking at the list of boxes in VirtualBox) as they're all named with the prefix "vladdefault" followed by a long unique string of numbers (see attached).
Anyone else seeing this? I'm unsure if this is due to a change in VirtualBox, Vagrant or Vlad. Either way, is there something we can do in Vlad to bring back use of the boxname variable? I know I can manually edit each box name in VirtualBox but that seems clunky compared to how it was automatically taking care of things before.