1. 21
  1. 11

    You will also be able to write configuration in HashiCorp Configuration Language (HCL) to limit the potential for mistakes or risk arising from dynamic configuration. This prevents arbitrary code execution inline in Vagrantfiles.

    The eternal struggle between “dynamic” and “static” configuration files fascinates me. It’s so enticing, at least initially, to use a script for configuration. And it works great, infinite flexibility. But then bad things happen, and the files become a jumbled mess (looking at you, setup.py). So we head back to the relative safety of a clean, safe, static file. Then someone goes “wait, I need to do X”, and the whole thing starts again (or we end up in some middle ground where we put code in a YAML file, like Ansible).

    1. 16

      The eternal struggle between “dynamic” and “static” configuration files fascinates me.

      You will probably enjoy Mike Hadlow’s treatment of the subject, with the introduction of the term “Configuration complexity clock”: http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html

      1. 1

        or we end up in some middle ground where we put code in a YAML file, like Ansible

        Stop, you’re reminding me of that time I had to write a CI job in Actions.

        1. 1

          Oh I know, CI configs are the worst! With Actions I always use a Docker container instead of installing and configuring crap on the runner, then the command it just “make test” or whatever. Docker files are at least somewhat less awful to write code in than YAML, and they can be kept kinda off on their own.

      2. 5

        I was such a heavy vagrant user years ago. I had single node and multi node hadoop cluster in vagrant and it just worked. I took it from job to job and was happy with it. Nowadays I use more docker and cloudy things, but I am happy to hear that they are still investing into vagrant.

        1. 4

          It’s good to see continued investment.

          Vagrant is still the best/most flexible option for local dev environments IMO.

          I’m somewhat curious how much the “run vagrant remotely” is driven by stuff like Apple shifting to Arm.

          Hopefully the move to Go brings back some stability too.

          1. 3

            Shame. The fact that vagrant is scripted with a sensible language without arbitrary limitations makes it much easier to use.

            1. 2

              indeed. I run a complete CI environment with vagrant, spinning up virtual machines for basically 90% of the available generic/* vagrant images, and scripting this with a central configuration file or specific provisioning scripts for specific virtual machines was really easy. I fear with vagrant shifting to go, i will have quite some trouble to port all this stuff, especially with all the cycles required to get it right.

              1. 2

                I get the impression from the Vagrant 3.0 heading, that with a plugin the existing ruby based vagrantfiles will still work:

                Once installed, Ruby-based Vagrantfiles and plugins will work normally.

                1. 1

                  yes, but i fear that might be limited to vagrant specific settings in the vagrantfile, probably not any ruby code that is within.

              2. 1

                I really hope they avoid second system syndrome because those changes sound pretty massive.