Vagrant-go: "Concurrent Vagrant runs don't work" topic

Vagrant
1

Howdy. I’m excited to see the improvements in Vagrant from its conversion to Go. Of course, I understand that such a conversion takes time and many steps. It’s especially nice that you-all are sharing the alpha-level code to get community input! Thank you, Vagrant Devs!

So, vagrant/vagrant_go.mdx at main · hashicorp/vagrant · GitHub … I currently have a utility wrapper script that parallelizes Vagrant runs, so that a Vagrantfile that specifies a slow deployment of 5 hosts with individual Ansible_Local runs takes 1/4 of the time of a serial run.

Here’s that script:

#!/usr/bin/env bash

# inspiration from https://stackoverflow.com/a/58907975/2808798

usage() { echo "Usage: $0 [-c <num_concurrent>] vagrant_command"; exit 1; }

while getopts ":c:h" opt; do
  case "${opt}" in
    c)
      concurrency=${OPTARG}
      ;;
    h)
      usage
      ;;
  esac
done

shift $(($OPTIND - 1))

vagrant_command="$*"

if [ -z $vagrant_command ]; then
  vagrant_command="up"
fi

if [ -z $concurrency ]; then
  concurrency=5
fi

vagrant status | \
awk '
BEGIN{ tog=0; }
/^$/{ tog=!tog; }
/./ { if(tog){print $1} }
' | \
xargs -P$concurrency -I {} vagrant $vagrant_command {}

Is this pattern unsupported? Yes, it is quite unsupported. But it Works For Me™. :slight_smile: Is a goal of the move to Go to do away with the need for this kind of ugly hackery by folks like me? :wink: Cheers!

P.S. Are you-all collecting statistics on the most commonly used community plugins in use?

2

Heya :wave:

this is a pretty neat use case. However, not one we test for when building new Vagrant features. Though we see not having the ability to have concurrent Vagrant runs a bug that should be fixed before Vagrant-go fully replaces Vagrant-ruby

Is a goal of the move to Go to do away with the need for this kind of ugly hackery by folks like me?

Moving Vagrant fully to go should come with some performance improvements and hopefully alleviate some pain the users have about Vagrant’s speed. Another part of this issue in particular is running things in parallel.
Currently, Vagrant does have an option for bringing machines up in parallel if the provider supports it. To find out you can check out the provider docs. Another option is to split up the steps of bringing a machine and provisioning it. So running a

# just bring up the machines (in parallel if your provider supports it)
$ vagrant up --parallel --no-provision
# this provision step should be done in parallel
$ vagrant provision

P.S. Are you-all collecting statistics on the most commonly used community plugins in use?

We are able to get some information about plugin popularity from Github statistics. Vagrant doesn’t collect telemetry data about plugins.

1 Like