As part of a Google Summer of Code project has been added a feature to allow users to set manually specific values of CPU and RAM.
The previous Compute Service abstraction assumed that all providers had hardware profiles, a list of profiles describing different cpu, memory and disk configurations that can be used to run a node. Some providers, such as ProfitBricks or ElasticHosts, do not have the hardware profiles concept and the previous implementation provides a fixed configuration with a fixed (hardcoded) list just to conform the interface. The new implementation allows to use custom hardwares or both (when supported) hardware profiles and custom hardwares.
Note that using hardware profiles provides hardware optimization or in some cases cheaper pricings.
There are two ways to use a custom hardware: setting in on the hardwareId or specifying cores and ram values using minCores and minRam.
When user set the hardwareId, the Template Builder first check if the provided hardwareId corresponds with an existent hardware profile, and if it corresponds, it would use it. In case that the provided hardwareId do not match with an existing hardware profile and have the automatic hardwareId format, it would use a custom hardware.
To set CPU and RAM with hardwareId you have to set the hardwareId using template builder with the format:
automatic:cores=2;ram=4096
as you can see in the following example:
{% highlight Java %} Template template = templateBuilder .hardwareId(“automatic:cores=2;ram=4096”) .build() compute.createNodesInGroup(“jclouds”, 1, template); {% endhighlight %}
In providers that configure disks based on the volume information provided in the hardware profile you have to specify also the disk size, like in ProfitBricks, where disk is mandatory, you need to specify it to use custom machines:
{% highlight Java %} Template template = templateBuilder .hardwareId(“automatic:cores=2;ram=4096;disk=100”) .build() compute.createNodesInGroup(“jclouds”, 1, template); {% endhighlight %}
To help building the automatic hardwareId, the automaticHardwareIdSpecBuilder utility creates an automaticHardwareId string with the provided values of cores, ram and optional disk size.
{% highlight Java %} Template template = templateBuilder .hardwareId(AutomaticHardwareIdSpec .automaticHardwareIdSpecBuilder(2.0, 4096, Optional.absent()) .toString())) .build() compute.createNodesInGroup(“jclouds”, 1, template); {% endhighlight %}
When user set minCores and minRam, first the template builder checks if a hardware profile matches with the provided minRam and minCores. If not, the templateBuilder will use the automatic hardware.
To set up custom hardwares using minRam and minCores you have to set them using template builder.
{% highlight Java %} Template template = templateBuilder .minCores(2) .minRam(4096) .build(); compute.createNodesInGroup(“jclouds”, 1, template); {% endhighlight %}
In providers that need to specify disk, set also minDisk:
{% highlight Java %} Template template = templateBuilder .minCores(2) .minRam(4096) .minDisk(100) .build(); compute.createNodesInGroup(“jclouds”, 1, template); {% endhighlight %}
There are several providers that support arbitrary values of CPU and RAM like Docker, ElasticHosts, Google Compute Engine, etc. The first available providers supported by the new feature are:
To configure the new feature in other providers add a bind() to the ArbitraryCpuRamTemplateBuilderImpl class at the provider's context module:
{% highlight Java %} bind(TemplateBuilderImpl.class).to(ArbitraryCpuRamTemplateBuilderImpl.class); {% endhighlight %}
Also is necessary to modify the function that transform a node from the provider model to the portable model of jclouds, to include the new automatic hardwareId (if apply).
Special thanks to Ignasi Barrera for all the help, Andrew Phillips for code reviews and the rest of jclouds comunity.
Of course, also thanks to Google for running GSoC.