Carlos, if you only need to provide custom CPU and RAM values, you can do it with the provider specific template options. Something like:
ComputeServiceContext context = ContextBuilder..... ComputeService compute = context.getComputeService(); TemplateOptions options = compute.templateOptions() .as(AbiquoTemplateOptions.class) .overrideCores(number-of-cores) .overrideRam(ram-in-mb); HTH! I. On 24 March 2014 10:40, Ignasi Barrera <[email protected]> wrote: > 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.
