Hi! That's a lot of insight for this ticket! You've pretty much nailed the design details - all I'd +1.
> * ..with the only inconvenient that users should know in advance if the provider "supports"..* This one, I have a solution I think. The general idea is to write an *extendabl*e* TemplateBuilder. *Let me describe how I've structured this: 1. TemplateBuilderWithDefinableProfile[1] - this interface (which extends TemplateBuilder) contains the most important method, *self,* which instructs implementing classes to return itself. This is where *fixedRam* and *fixedCores* method would go. 2. TemplateBuilderImpl[2] - The original TemplateBuilderImpl would then implement the above interface, and in it's *chaining methods* will return *self *instead. Both fixedRam and fixedCores method delegates to minRam and minCores, respectively, by default. 3. ProfitBricksTemplateBuilderImpl[3] - As to the *specializing* types, they'll need to override *self*, and fixedRam + fixedCores, if applicable. Although the class type is *not-so-pretty* due to the self-referencing generic types, this setup would eliminate the need to cast to concrete types. Thoughts? RJ [1] https://github.com/devcsrj/jclouds/commit/5e37bdbbaea19dfaf19009141481153e2590476a#diff-7d594c26c63be997952f350df0ba23b8R21 [2] https://github.com/devcsrj/jclouds/commit/5e37bdbbaea19dfaf19009141481153e2590476a#diff-15cd007529dca3165ee1194447fadf3fR1164 [3] https://github.com/devcsrj/jclouds-labs/commit/64cf56148a089e6797652cd8d1540d7d64ec6144#diff-1500f3a9004863afdd8a7869407b390aR44 On Mon, Jan 18, 2016 at 11:45 PM Ignasi Barrera <n...@apache.org> wrote: > Hi! > > It would be very nice to have JCLOUDS-482 [1] implemented for 2.0.0. > I've been thinking about it and there are several approaches to > implement it, so I'm sharing my thoughts here and hope we can discuss > how to better implement the feature. > > The current ComputeService interface defines the > "listHardwareProfiles()" method, that lists the available hardware > configurations one can use to create the nodes. When using the > portable abstraction, users specify a "minRam" and a "minCores" and > the TemplateBuilder default implementation finds the best matching > profile from that list, and creates the node using it. > > If we want to implement the arbitrary CPU and RAM feature in the > portable interface, there are (at least) three points to address: > > * What should the "listHardwareProfiles()" call return? > * How should the TemplateBuilder "resolve" those fixed CPU and RAM values? > * When listing nodes, each node has a "hardware" property with the > info of its hardware profile. How should we populate that (currently > most providers do a hardware profile lookup based on the hardware id). > > > After having thought a bit about this: > > * Returning an empty set in the list call could ve a valid way to > indicate there are no preconfigured profiles. > * Abusing the "minRam" and "minCores" seems confusing to me. I'd > rather create a specialisation of the TemplateBuilder that exposed a > "fixedRam" and "fixedCores" (or similar). This way only the providers > that really support arbitrary cpu and ram would bind that impl to the > Guice context and the code would not cause any misunderstanding. > * Assume that the TemplateBuilder will construct a Hardware [2] > implementation on the fly based on the provided info (cpu, ram, > disk?), and pass it to the ComputeService to create the nodes. > Eventually, then listing the existing nodes we assume we should be > able to also construct a Hardware instance given the information in > the node. (We should also create an auto-generated id for that > Hardware instance). > > I think this is the simplest way to implement that, with the only > inconvenient that users should know in advance if the provider > "supports" an arbitrary cpu/ram to cast the TemplateBuilder to the > "fixed" implementation, to "see" the fixedCpu and fixedRam methods. > > > WDYT? Other ideas? > > > Thanks! > > I. > > > > [1] https://issues.apache.org/jira/browse/JCLOUDS-482 > [2] > https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/domain/Hardware.java >
