There is no work in progress yet, but it has been added in JIRA [1] and also proposed as a GSoC projcet (no students applied to it, though). I'm willing to implement it, but I'm lacking time at the moment. I can help if anyone wants to take it anyway!
I. [1] https://issues.apache.org/jira/browse/JCLOUDS-482 On 24 March 2014 09:58, Carlos Garcia Ibañez <[email protected]> wrote: > Hi all! > In the current phase of our project we are planning to move into a more > abstract layer, so we are trying to use the ComputeServiceContext interface > to manage our deployments, instead of the more specific AbiquoContext. One of > the issues we are facing is that this way lose the ability to provide custom > hardware configurations, but can only use predefined hardware profiles. I've > found the attached mail (written by Ignasi at the beginning of the year), and > I was wondering if there is any work in progress on this. > Thanks in advance. > > -----Original Message----- > From: Ignasi Barrera [mailto:[email protected]] > Sent: 09 January 2014 00:16 > To: <[email protected]> > Subject: Modeling providers that don't have Hardware Profiles > > 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 > > > Click > https://www.mailcontrol.com/sr/RCMtqZ3nsiDGX2PQPOmvUrxf8JpNKDSo5cxARf5NGTMURwRqvLMtbuG9Ak5m+VjL6!d5cSRWK9Ueq4Nrivo6iw== > to report this email as spam.
