> + @Named("DEFAULT") Provider<TemplateBuilder>
> defaultTemplateProvider) {
> + super(locations, images, hardwares, defaultLocation, optionsProvider,
> defaultTemplateProvider);
> + }
> +
> + protected Hardware automaticHardwareForCpuAndRam(double cores, int ram) {
> + return new HardwareBuilder()
> + .id(automaticHardwareIdSpecBuilder(cores, ram).toString())
> + .ram(ram)
> + .processor(new Processor(cores, 1.0))
> + .build();
> + }
> +
> + protected Hardware findHardwareWithId(Set<? extends Hardware>
> hardwaresToSearch) {
> + try {
> + return super.findHardwareWithId(hardwaresToSearch);
> + } catch (NoSuchElementException ex) {
Is catching an exception and falling back the best way of doing this? Would the
following alternative perhaps also work?
```
if (isAutomaticId(...)) {
// do stuff for automated IDs
} else {
// fall back to original behaviour
}
```
The immediate challenge I can see with this is that users _might_ have existing
hardware IDs that match this scheme. Is there a way we can avoid this by not
"overloading" the ID in some way?
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/984/files/55c696c2ba870e202cfb8e42734e66bb31aab7b4#r73571672
