For the first question, I'd propose to have a default (just one)
hardware profile for providers that don't support preconfigured
profiles.
+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?
For the second question... I don't have a proposal yet :) Should we
return the "closest" preconfigured hardware, or should we configure
the explicit values set in the template builder?
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?
Regards
ap
