I think it is OK to just implement a simple parser. The scope of the project is not to allow specifying complete hardware profiles, but adding basic support for arbitrary cpu and ram, which should set the foundation to implement the complete approach with little effort.
Regarding the default value for CPU and RAM, I think it is OK to provide a "default hardware profile", but we have to think about the following use cases so we properly cover them in a way that we're all happy with. There are two premises: 1. Some providers have preconfigured hardware profiles but also support setting arbitrary CPU and RAM (Google is an example). 2. We assumed that providers that don't have hardware profiles would return an empty list in the "listHardwares" method. With these two premises in mind, we need to answer the following questions: 1. What hardware should be resolved when the user configures a template in one the following forms? - templateBuilder().build(); - templateBuilder.smallest().build(); - templateBuilder.biggest().build(); - templateBuilder.fastest().build(); 2. In a provider that has preconfigured hardware profiles and also supports explicitly setting arbitrary cpu/ram values, what hardware should be resolved when building a template like: - templateBuilder.minCores(2).minRam(2048).build(); For the first question, I'd propose to have a default (just one) hardware profile for providers that don't support preconfigured profiles. All methods should then resolve the default one. For provider that support both approaches, like google, those methods should just consider the preconfigured profiles. For the second question... I don't have a proposal yet :) Should we return the "closest" preconfigured hardware, or should we configure the explicit values set in the template builder? Should we have a way to tell the template builder that we want a preconfigured profile or a custom one? (this would conflict with what we agreed to "reuse" the "minCores" and "minRam" methods). Please discuss! :) On 22 June 2016 at 20:01, Iván Lomba <lombarodriguezi...@gmail.com> wrote: > Hi! > > For the first approximation I've picked the format: > "automatic:cores=2;ram=1024" > > Initially in my first approach I assumed that the user specified both CPU > and RAM, but as Ignasi pointed at my first commit, maybe we should have > default values and let the user specify only > CPU > or RAM or even none. Thoughts about this? > > I did a small utility to parse automatic ids. In order to make it more > extensible I was thinking if use a > "parse > scheme > " > as in the hardwareSpec: different parsers with a Map that relates keys with > parsers, but it seems excessive to me for the moment, considering that only > ram and cores are parsed. > > BTW, I'm pushing at this branch: > https://github.com/ivanlomba/jclouds/tree/gsoc2016-JCLOUDS-482 > > 2016-06-15 19:55 GMT+02:00 Ignasi Barrera <n...@apache.org>: > >> +1 to use parseable ids. >> >> Regarding the format, let's pick one that allows us to easily extend it in >> the future, in case we need to add there other hardware profile information >> such as disk sizes, etc, but keep it as simple as possible to cover the >> current use case. >> >> I. >> El 13 jun. 2016 1:47 p. m., "Iván Lomba" <ivanlo...@gmail.com> escribió: >> >> > Hi! >> > >> > I'm going to start with the implementation to support cpu and ram. >> > According with discussed here before, I understand that the best approach >> > will be to have auto-generated hardwares, and to take advantage of >> minCores >> > and minRAM to avoid interface changes and casts. >> > >> > Regarding the ids, I'm not sure about what is better or what has more >> > sense: if using randomIds, parseableIds or even combine it? What do you >> > think? >> > >> > Parseable ids that allow to reconstruct the hardware from the id seems to >> > me an useful option. If we decide to use that approach, what format can >> we >> > use? Something like: >> > >> > "automatic-cpu-5-ram-2048..." >> > >> > Regards. >> > >>
