Tweak RAM allotment for Vagrant VMs

[aneeshusa]

The Vagrant machines have a dual usage: not only are they used to check that the Salt states run successfully, but they're also used to actually try to build Servo to make sure the Salted configuration is correct. For the first use case, it's nice to be able to just vagrant up, and see that all the machines successfully came up, so right now the Vagrantfile has 1 GB / VM or 4 GB total, which is reasonable to allot on a laptop. However, actually building Servo takes more RAM (at least 3-4 GB apparently?); this is mitigated by the fact that you're likely to only spin up one VM at a time while investigating Servo build failures.

We should figure out a way to tweak the RAM allotments to support both use cases more easily than just editing the Vagrantfile by hand.

Refs #239

[aneeshusa]

https://www.virtualbox.org/manual/ch04.html#guestadd-balloon might be useful for this.

[aneeshusa]

https://www.virtualbox.org/manual/ch04.html#guestadd-pagefusion may also help to decrease memory usage. Virtualbox's page fusion is only supported for Windows guests.

[larsbergstrom]

Do you want to actually land this or wait and just have people do this one-off instead? I do worry that it'll make it hard for people on less-massive machines to do a full vagrant up without getting things killed.

[aneeshusa]

Right now, I'd like to wait and just do a one-off when needing to try to build Servo; I find this happens a lot less than vagrant up. The best thing would be if you could just add RAM on the fly to a single machine (e.g with a Virtualbox or Vagrant command), but apparently this can't be done.

[aneeshusa]

2 ideas:

• Define 2 VMs for each node type in the Vagrantfile: one with 1 GB that comes up on vagrant up, one with 4 GB that doesn't autostart, with a -bigmem suffix. Use the first set regularly, but be able to use the second set to debug Servo build failures. This is easier to implement, but has the disadvantage that if vagrant up is successful, you need to sit through provisioning again while bringing up the secondary VM.
• Build a Vagrant plugin that either adds a command line option to vagrant reload or a new command which will restart a VM with more memory. This will take longer to develop, but should be faster during usage since there's no need to run provisioning again.

Thoughts?

[larsbergstrom]

I think I'm actually OK with just leaving it at 1GB. All of the provisioning-related stuff on Linux will be tested by a build, even if it fails near the end (when rustc is compiling the script crate). By then, we'll have touched all of the compilers, installed system libraries, etc. and are in the final end run on Rust code.

I only really cared here because I also wanted to confirm that the linker was getting properly symlinked, as it gets hit at the end. Though, hrm, maybe that's something we do care about and should need a full build for?

I guess that since it's easy enough to change and you usually know if you're making changes that you want to do a full build to test, it's probably fine to just mention it in the section of the wiki documentation around Vagrant.

[larsbergstrom]

@Manishearth @edunham Do you have an opinion here?

[edunham]

It sounds to me like 1GB of RAM is fine for a majority of cases, and leaving it as the default will create a better first experience for people on older hardware trying to help out with the project than increasing it.

I agree that documenting how to increase RAM when needed in the wiki would be a good idea. Right now the README links into https://github.com/servo/servo/wiki/Buildbot-administration, which doesn't have any Vagrant info. Perhaps the target audience of the README would benefit more from linking to an overview page discussing how to locally test changes?

[aneeshusa]

For now, I'll add info about how to edit the Vagrantfile to add memory; it sounds like this won't be too inconvenient after getting documented.

@edunham The Vagrant info actually is on the page, in this section: https://github.com/servo/servo/wiki/Buildbot-administration#making-changes. Do you have suggestions about how to re-organize the page to make this information easier to find?

[edunham]

@aneeshusa I skimmed the page for a section heading looking like 'vagrant' or a block of Vagrant commands. I've edited the page to make the correct instructions easier to spot. Sorry about that!

[aneeshusa]

We've documented on the wiki how to increase VM memory by editing the Vagrantfile, and this is easy enough to do when necessary that we don't need anything more complicated.