+1 @devcsrj also proposed this approach this morning on the IRC channel (I had a pending email update with the relevant bits) and seems the best one. No casts and no interface changes.
We can provide a template builder impl with thenew logic in core-compute, so the providers supporting that will just have to bind it. Regarding the random id, agree. It should be something that makes it clear thst the Hardware profile does not really exist in the provider. It could even make sense to have a subclass of HardwareImpl to represent and properly qualify these profiles. FTR: The logs of the #jclouds IRC channel are always made publicly available here: https://botbot.me/freenode/jclouds/ El 19/1/2016 6:02 p. m., "Andrew Phillips" <andr...@apache.org> escribió: > WDYT? Other ideas? >> > > +1 on using an empty set of hardware profile to indicate "does not use > profiles", and on using auto-generated Hardware objects, in response. > > It would be nice if the (random?) ID of those object somehow corresponded > to the request to make it clear that these are really "ephemeral" objects, > i.e. requesting the same specs twice would give you two Hardware objects > with likely the same values, but with different IDs. > > The part I'm not yet sure about is the 'fixed*' thing. From what I > understand, a Template intends to semantically represent the minimal > required specification - you want something back that (ideally) gives you > exactly that, or, if not available, a little bit more...but not waaaaaaaay > more. > > From that perspective, it doesn't seem so bad to me to say that if you ask > for a template with minRam = X and minCores = Y, some providers can give > you *exactly that* back - good for you! At any rate, it seems less > potentially confusing to me than to take a concept (the Template) that > generally talks about *minimum requirements* and add two arguments that > suddenly talk about *exact specs*. > > The question that would remain is whether, for a profile-less provider, it > would be "wrong" to return a Hardware instance that has more than the > minRam and minCores requested. Irrespective of the answer, I would assume > that the providers could simply be implemented to ensure this didn't happen > - i.e. if the user asks for minRam = X and minCores = Y and the provider > allows you to provide exactly that, then you should do it. > > Regards > > ap >
