vagrant

* try to find a solid reliable "box" to launch

* ensure your virt provider is supported and configured

* create a vagrant file and configure it

* "vagrant up" and more vagrant-specific provisioning in the vagrantfile.

* Destroy the vm and then have to toil through provisioning again if you didn't export your "box"

multipass (same on macos/linux/windows)

multipass launch -n my-machine -c 2 -m 4G -d 20G bionic --cloud-init my-cloud-init.yaml

So besides the fact that this tool has exactly the same “problems” you describe in the first two points (see another sub thread for MacOS vs Linux host running this tool - different images are available; and you’re just trusting that “bionic” is a “solid reliable” image to use), the rest of your complaint is: “I don’t want a file that defines my one or 100 vm setup so I can commit it to the project. I want to run a command and define the same attributes over and over again every time any person on the project needs to use it”.

Also I don’t know why you mentioned “vagrant destroy” and then went on about “toil through your provisioning”.

If you want to use cloud init, there is a vagrant provisioner that supports it. If you don’t, you can use another one like shell scripts or chef or salt or puppet or Ansible or whatever.

If you destroy the machine the provisioning will need to run again - yes. But why would you destroy the machine if you don’t want it to start from scratch? But what toiling is there? Once the provisioners are defined, you just let them run - how is that different than a cloud init provisioned vm?

> If you want to use cloud init, there is a vagrant provisioner that supports it

Are you referring to this? Looks like it only works for virtualbox provider. https://github.com/jameskeane/vagrant-cloudinit

My main point is simplicity wins. No need to mess with providers and plugins and tooling/provider/plugin specific provisioning logistics.

Cloud-init is becoming the de-facto machine provisioning format, it's great to be able to hack on it locally and get the same results elsewhere. Sharing it is great as well, install multipass and point to the cloud-config. Done.

> If you destroy the machine the provisioning will need to run again - yes. But why would you destroy the machine if you don’t want it to start from scratch? But what toiling is there? Once the provisioners are defined, you just let them run - how is that different than a cloud init provisioned vm?

Fair enough! I agree which you here it was probably a bad example on my part.

> Once the provisioners are defined, you just let them run - how is that different than a cloud init provisioned vm?

Which provisioner for which provider? And what plugins does it need? cloud-init is just more simple and portable to use IMO.

> My main point is simplicity wins.

Not true. The moment you need to do anything too complex for a simplistic tool, simplicity loses. Multipass doesn't do CentOS, for example. Therfore, for some of my use cases, multipass's simplicity loses.

Furthermore, with multipass, as soon as you need to do anything beyond launching a default image, it's no longer simple. It's just as complicated as Vagrant. Someone has to write your cloud-config.yaml file, just as someone has to write an Ansible playbook.

Multipass on Linux does CentOS and any other cloud-init enabled image.

It currently does not support this for some reason on macos which really sucks! Hopefully it will eventually.

I also want to say that I enjoy using Vagrant as well. It certainly has it's advantages for certain use-cases. For my personal most common use-case, I prefer multipass. That's all! Glad to see there are multiple options continuing to evolve in this space!

Completely agree. I do not see any advantage here.

To add: Virtualbox is supported on Windows/Mac/Linux, is trivial to install, and is the default Vagrant provider. If I want top performance, I can choose other options. Vagrant+Parallels on Mac is nice. So is Vagrant+KVM on Linux.

A Vagrantfile is 4 lines for a basic config, and vagrant will create one for you, and your config is saved should you need to edit it. It's trivially easy. Multipass has the same needs the moment you need anything beyond the defaults. So I'd call that a wash.

How is "vagrant up" harder than "multipass launch"?

What does "vagrant-specific provisioning" means exactly? Vagrant provisions with the same toolchain you are probably using for your production servers. It supports ansible, chef, and puppet. How is that "vagrant-specific"?

When I want to launch a development vm, I want it provisioned in specific ways that match the production instances I will eventually be launching. Vagrant+Ansible gives me that in spades, and it's easy.

The Hashicorp toolchain and ecosystem also provides other advantages: Packer for easily building my own base images, and targeting them at multiple hypervisors, including EC2. Not to mention that all distros are supported. Packer also answers the GP's provisioning complaint. Provision a VM, and use it as the basis for a new box in Packer. Problem solved.

This reminds me of people who like MySQL "because it's easier than Postgres." Not easier. Just not the same.

I tend to agree, vagrant offers way better configuration possibilities and flexibility. However, there is one significant benefit: on macOS multipass uses hyperkit/xhyve to run the VM, which in my experience performs _much_ better than virtualbox ("docker for mac" also uses hyperkit). I'd love to see a vagrant hyperkit provider (or even a multipass provider! :-), but sadly have found nothing beyond a few alpha-level sketches so far.

This is true. Virtualbox is a pig pretty much everywhere.

Veertu used to ship Veertu Desktop (using Hypervisor.framework, and able to ship via the App Store) and claimed to be supporting vagrant at some point, but then they changed approach completely and focus purely on virtualising macOS for CI build environments now.

Personally I always use either VMware Fusion or Parallels with vagrant anyway (well unless I'm debugging some weird vagrant/vbox issue for someone else).

It'd be nice to have an actively maintained provider that's backed by the built-in framework, but the only one I'm aware of stopped development 3+ years ago.