Add logic for total disk space and memory tunings

[slsnow]

• It would be ideal to have a single value that is set for sumaserver disk space, and then partitions adjust accordingly
• It would also be nice to have some tuning parameters that react to this as well.

[ZeTopHat]

This was something I noticed when deploying the lab. My system was not ready for a 32GB RAM system and ended up getting oom-killer invoked. I forgot just how much RAM the suma sucker can need. However, in a lab environment, I wonder if 16GB wouldn't be more reasonable?

I would normally recommend utilizing the "libvirt" section of the custom.yaml for changes the deployer makes. It is an odd case when it is lab-specific though. My approach up to now has been 1) set machines with specific needs to specific values, 2) allow the custom.yaml to determine the values of all other machines. There's some machines that I'm not sure would be good for the deployer to manipulate. Perhaps we could have a custom.yaml value along the lines of "minimalrequirement" vs "idealrequirement" that would be either true or false. e.g. minimalrequirement: true means that suma deploys with 16GB of RAM and a default of false uses the 32GB of RAM? Just spit balling here.. Of course I'm not sure how much of this will apply to your specific lab since your Vagrant deploy is quite forked from the others.

On a slightly adjacent topic, I think we could also add logic to the Vagrantfile template in general (this may not apply to yours?) that sets a minimum RAM/CPU/Disk requirement that exits the deploy if the custom.yaml does not satisfy the requirement for a machine to be deployed.

[slsnow]

Thanks for the feedback.

Even 8 GB is fine for a small lab environment, but 16G is probably a good default, I just wanted 32G for the training deployments, since that's the most ideal and we had the capacity for it. There are also some SUMA settings that could be set during provisioning based on these values, that would allow things, even syncs, to be a bit faster if you have 16 or 32.

I like that idea for the custom.yaml setting where it at least has some quick settings, and of course more tweaking can be done in the labs and machines configs if you want something more specific.

My client machines take the custom.yaml libvirt values, so that's probably a good idea. For example, SUMA clients piss off salt if they have less than 1G of ram, so it would be good to have a check on there that fails or gives a warning at least if you're under certain requirements.