> +1 to this. Ideally, it would be easy for the user to discover what that
profile is ("listHardwares" shouldn't really return it since it's not
actually a "real" provider profile?), and perhaps even to configure it
themselves. The latter is something we can leave as a provider-specific
implementation ("jclouds.my-provider.default-profile-json" or whatever);
not sure about the issue of how a user would discover what that profile is,
though?I was thinking about binding it to the Guice context. Users will be able to override it and the binding would be just set by the providers supporting this. We could create a Guice module with the defaults and let the providers include it or not. > Would the following work here: > > 1) Use the existing resolution logic to pick the "best match", just as if the provider didn't support arbitrary attributes > 2) For those attributes where the provider *does* support arbitrary values, override the values in the profile from step 1) to match the user's request > > ? This should result in the "closest profile possible" to the user's request that the provider can support, which I think is what we are interpreting the template to mean? The only inconvenient I see in this approach is that we'll have to potentially change the id to the auto-generated one, and perhaps providers do something more than just configuring the values we pass in the profile object. This would effectively mean that we won't be using the preconfigured profiles at all, and we might be missing hardware optimizations. Also custom configurations might have different pricings. In any case, I see this as a good starting point. As an example, in Google Compute Engine you just pass the URL of the profile, being it a specially encoded one when using custom values (see the machineType parameter at [1]), so there is actually only a profile id being passed. P.S. @ivan we'll have to see how instances with custom machineTypes are returned and how jclouds shows them now, to understant what we have to adjust there. Also, once we have the basics in place, the Google implementation would have to do something to refine the user criteria to build the closest valid profile that meets all the restrictions [2] (but let's get the basic behavior working first). [1] https://cloud.google.com/compute/docs/reference/beta/instances/insert#request-body [2] https://cloud.google.com/compute/docs/instances/creating-instance-with-custom-machine-type#create
