Thanks a lot, Ignasi, I'll give it a try! -----Original Message----- From: Ignasi Barrera [mailto:[email protected]] Sent: 25 March 2014 10:20 To: Carlos Garcia Ibañez Cc: [email protected] Subject: Re: Modeling providers that don't have Hardware Profiles
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.
