Re: JCLOUDS-482 - Add support for arbitrary CPU and RAM in the ComputeService

[Iván Lomba <iv...@gmail.com>]

Hi!

After talking with Ignasi about what hardware should be resolved when a
provider support fixed values and hardware profiles (like Google), the best
option seems to be that unless user specify the hardwareId(with the
existent hardware) the template builder always create a fixed hardware.

Other options will be introduce some flag to determine whether or not use
hardware profiles, or to configure an "acceptable" distance to the nearest
hardware profile, and only use hardware profiles inside of that range, but
both options can be confusing for users.

Regards!



2016-06-28 7:41 GMT+02:00 Ignasi Barrera <na...@apache.org>:

> > +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
>