4 ms·

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 * "v

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

stephenr 7y ago
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?
- teilo 7y ago
  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.
- moondev 7y ago
  > 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 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.
  - teilo 7y ago
    > 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.
    - moondev 7y ago
      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!

stephenr 7y ago

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?

teilo 7y ago
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.
moondev 7y ago
> 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 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.
- teilo 7y ago
  > 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.
  - moondev 7y ago
    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!