Page MenuHomePhabricator

Allow roles to effect pre-provision changes to MW-Vagrant settings
Closed, ResolvedPublic

Description

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Acceptance Criteria

  1. Roles define setting requirements in a way that's congruent with our current roles implementation. (No scary stuff.)
  2. 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.
  3. 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.
  4. Enabling or disabling a new role that defines settings should tell the user about the changes and prompt for a reload if necessary.

Event Timeline

dduvall created this task.Mar 12 2015, 7:28 PM
dduvall claimed this task.
dduvall raised the priority of this task from to Medium.
dduvall updated the task description. (Show Details)
dduvall added a project: MediaWiki-Vagrant.
dduvall added a subscriber: dduvall.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 12 2015, 7:28 PM

I'm currently thinking of something like puppet/modules/role/settings/<role>.yaml the first requirement.

dduvall updated the task description. (Show Details)Mar 12 2015, 7:33 PM
dduvall set Security to None.

Definitely. I had that problem for T91661 - jobrunner couldn't start because cassandra was eating all of the memory. Upping the mem to 2GB would solve the problem, but publishing a role with a you need to do stuff before installing this role disclaimer hardly felt like an acceptable solution. Finally, I resolved it (if you can call it that) by fooling the system into thinking it's in RUNLEVEL 1 so that it wouldn't start cassandra after installing it, thus giving jobrunner enough wiggle room.

I'm currently thinking of something like puppet/modules/role/settings/<role>.yaml the first requirement.

+1. That's even easier than finding out that the vagrant::settings class exists.

In that file, one could easily point out the requirements needed by the role. This could be also used as a safety-check mechanism. E.g., the role states there it needs 2G or RAM, but if the host has less than, say, 4G in total, roles/enable could inform the user they might experience performance degradation / issues.

dduvall added a comment.EditedMar 12 2015, 9:43 PM

This could be also used as a safety-check mechanism. E.g., the role states there it needs 2G or RAM, but if the host has less than, say, 4G in total, roles/enable could inform the user they might experience performance degradation / issues.

I like that idea, but how do we define the threshold for a reliable warning? We could check for free memory and base it on some percentage but I'm not sure what that percentage would be and free memory is a constantly moving target.

Change 196492 had a related patch set uploaded (by Dduvall):
plugin: Role settings feature description

https://gerrit.wikimedia.org/r/196492

Change 197251 had a related patch set uploaded (by Dduvall):
Port vagrant::settings to new role settings system

https://gerrit.wikimedia.org/r/197251

Change 196492 merged by jenkins-bot:
plugin: New role settings system

https://gerrit.wikimedia.org/r/196492

Change 197251 merged by jenkins-bot:
Port vagrant::settings to new role settings system

https://gerrit.wikimedia.org/r/197251