Hi! It would be very nice to have JCLOUDS-482 [1] implemented for 2.0.0. I've been thinking about it and there are several approaches to implement it, so I'm sharing my thoughts here and hope we can discuss how to better implement the feature.
The current ComputeService interface defines the "listHardwareProfiles()" method, that lists the available hardware configurations one can use to create the nodes. When using the portable abstraction, users specify a "minRam" and a "minCores" and the TemplateBuilder default implementation finds the best matching profile from that list, and creates the node using it. If we want to implement the arbitrary CPU and RAM feature in the portable interface, there are (at least) three points to address: * What should the "listHardwareProfiles()" call return? * How should the TemplateBuilder "resolve" those fixed CPU and RAM values? * When listing nodes, each node has a "hardware" property with the info of its hardware profile. How should we populate that (currently most providers do a hardware profile lookup based on the hardware id). After having thought a bit about this: * Returning an empty set in the list call could ve a valid way to indicate there are no preconfigured profiles. * Abusing the "minRam" and "minCores" seems confusing to me. I'd rather create a specialisation of the TemplateBuilder that exposed a "fixedRam" and "fixedCores" (or similar). This way only the providers that really support arbitrary cpu and ram would bind that impl to the Guice context and the code would not cause any misunderstanding. * Assume that the TemplateBuilder will construct a Hardware [2] implementation on the fly based on the provided info (cpu, ram, disk?), and pass it to the ComputeService to create the nodes. Eventually, then listing the existing nodes we assume we should be able to also construct a Hardware instance given the information in the node. (We should also create an auto-generated id for that Hardware instance). I think this is the simplest way to implement that, with the only inconvenient that users should know in advance if the provider "supports" an arbitrary cpu/ram to cast the TemplateBuilder to the "fixed" implementation, to "see" the fixedCpu and fixedRam methods. WDYT? Other ideas? Thanks! I. [1] https://issues.apache.org/jira/browse/JCLOUDS-482 [2] https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/domain/Hardware.java
