TFA, or any least the quote you have selected, does not explain what it is. It states (in quite ambiguous terms) what the combination of Vagrant and "existing virtualization providers" can achieve but not what Vagrant's role is.

From http://www.vagrantup.com: "Create a single file for your project to describe the type of machine you want, the software that needs to be installed, and the way you want to access the machine. Store this file with your project code"

That, and http://docs.vagrantup.com/v2/why-vagrant/, sounds quite similar to a configuration management tool to me (I believe you that it's not, I'm just saying I wouldn't have understood that). Seems geared to launching instances/VMs too perhaps. Maybe it's my lack of domain knowledge and maybe I have unfair expectations but I think that the sales pitch should be accessible to a developer who's not solely in the "DevOps space".

Accessibility is good because I'm sure it is incredibly awesome and may well be useful to a broader set of people who aren't yet in the loop.

With vagrant, I can create a vagrantfile. This says: "create a VM using this basic distribution, this networking configuration, these forwarded ports, and this hardware exposed". It defines the basic machine.

I can then use "vagrant up". This creates a new VM using Virtualbox, VMware, or whatever I have installed (I think there's even EC2 providers now!). It configures that VMs hardware as above.

Then, vagrant can use one of many tools in the configuration space -- Chef, Puppet, Salt -- to configure the software in the VM.

I guess the distinction lies there: vagrant configures hardware. Salt et all configure the software.

The quote that SandB0x posted (it comes from vagrantup.com) says that it can be used for defining "the software that needs to be installed". So is the distinction Vagrant : h/w + s/w, Salt et al : s/w?

It's more that you use configuration management for the software, and then Vagrant does the hardware and hands control over to your configuration management for the software. Vagrant can also do the software itself, yes, but the way of doing so is running shell scripts, so it's far preferable to use a configuration management tool (the main benefit being idempotence).

The quote seemed pretty clear to me, but I suppose that could be because I already know what it does. Vagrant wraps VM software (VirtualBox, VMWare, etc — the "existing virtualization providers" in the quote) to create disposable development environments. It also allows you to connect with configuration management tools like Chef or Puppet, which then configure that disposable environment to mirror your production environment. It doesn't really do configuration on its own (unless you count running shell commands), so it isn't a configuration management tool itself. It does one thing well.

I agree that we should be evangelizing DevOps and bringing more people into the loop. I was simply saying that Vagrant itself doesn't really need any marketing. It's hard to read much of anything about the field without seeing it mentioned.

Thank you, your explanation finally made me clearly understand what these tools are for. I constantly hear about them, have read their landing pages, and even listened to a talk on Vagrant + Puppet, but still didn't understand what it is exactly that these tools do (and do differently).

Vagrant doesn't need more marketing, but it -- and the other tools -- do need to explain clearly what it does (and does not) do in a way that non-DevOps folks can understand. Perhaps the easiest way to do that is with a simple use case.

I couldn't agree more that most of the tools in this area could benefit from some better explanations and best practices. The development is happening at such a rapid pace that it becomes very difficult for a newcomer to figure out what's going on. I talked to someone at Opscode about it yesterday and he agreed, and said that it's something they are working on, so hopefully this will get better soon.