Yes, that builder pattern would work. The concern I was referring to is that even with this approach, users will be calling compute.templateBuilder(), which returns a TemplateBuilder. They will still need to cast it to a TemplateBuilderWithDefinableProfile (based on the provider or on an "instanceof" check) in order to get access to the fixed methods.
This is the exposed ugly part of this approach. On 19 January 2016 at 09:45, Reijhanniel Jearl Campos <devc...@gmail.com> wrote: > 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 >>
