If a role needs to make some change to a MW-Vagrant setting—e.g. require more memory, CPU cores, forwarded ports, etc.—it currently does so by defining a vagrant::settings Puppet resource which drops a YAML file in the vagrant.d directory to be merged with the core settings' default values and whatever has been customized via vagrant config. This approach has a few major drawbacks.
- Most settings are only applied when the VM is spun up or reloaded. We have a special provisioner that reloads the VM upon the next provision, but it's an unsatisfactory extra step which is not communicated well to the user.
- The above leads to a chicken-egg scenario for services that require increases to vagrant_ram or additional forward_ports to function at all—i.e. they need to be applied /before/ the service is actually started, so before vagrant provision.
- Most settings written to vagrant.d completely overwrite the default or custom ones instead of augmenting them. This can lead to conflicts between two or more roles that change the same setting, the result of which is indeterminate.
- Disabling a role does not remove the settings from vagrant.d. This is indicative of a greater issue with our roles system, namely that we don't support negative role declaration (ensure => absent).
We should implement a new role settings system that addresses these issues but is still simple enough to adopt for those wanting to author a new role.
- Roles define setting requirements in a way that's congruent with our current roles implementation. (No scary stuff.)
- Changes to settings are made relative to the current or default value. For example, defining a role setting for vagrant_ram of 200 would increase the current value of vagrant_ram by 200, not overwrite it completely.
- Users are made aware of a role's changes to core settings in the role's documentation—vagrant roles info should tell them about it.
- Enabling or disabling a new role that defines settings should tell the user about the changes and prompt for a reload if necessary.