Hi! We've recently been discussing the convenience of adapting the ComputeService interface to those providers that don't have Hardware Profiles. Providers such as CloudSigma, Abiquo or Profitbricks allow users to specify arbitrary CPU and RAM values, so the ComputeService abstraction should be flexible enough to provide that.
Currently those providers return a hardcoded list of hardware profiles with reasonable values, but that limits users to that predefined list, which cannot always be good. One way to bypass that, is to provide provider specific TemplateOptions that allow to override the CPU and RAM, but that solution is not portable. After discussing the best way to achieve this without starting a major refactor of the ComputeService, the proposal is to create an alternate TemplateBuilder implementation for those providers that: * Does not rely on the list of hardware profiles. * Internally creates a Hardware Profile with the provided configuration, and builds the Template object using it. That would allow users configure the desired values for the CPU and RAM with the TemplateBuilder and get the noes created with those values. This implementation, however, has a small (but important) implication: what should the "listHardwareProfiles" method in the ComputeService return in that case? The proposal is to return an empty list (just like providers already do with the listLocations method when they are extracted from the metadata). The contract, until the entire workflow is refactored to cover the "non-hardware-profiles" providers, could be that providers that don't return a hardware profile list, allow arbitrary CPU/RAM configurations. This should allow integrations relying on the returned list, check if they should present a list or ask for literal values for the CPU/RAM, etc. WDYT? Ignasi
