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. > > >
