jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <notificati...@github.com>
Subject Re: [jclouds/jclouds] [JCLOUDS-1108]: shorten hardwareId (#951)
Date Thu, 05 May 2016 12:45:16 GMT
@nacx @andreaturli My opinion is that we should offer a consistent cloud abstraction with jclouds.
I don't think any of the other providers require the region to be included in the hardwareId,
so ideally we shouldn't require it for GCE.

(Is that statement true? Do any other providers include the region/zone in the hardwareId?)

But I'm not yet sure how we'd achieve that while maintaining consistency between listHardwareProfiles
and template options!

Some general thoughts/observations below.

---
As for some machine-types (i.e. hardwareIds) not being available in some zones, that is also
true for aws-ec2 (new hardware profiles are usually introduced in just a sub-set of regions
first). We are happy to use the simple name in jclouds, but then AWS is a bad example because
their API doesn't let you list the machine-types!

Looking at how Google themselves present this in the CLI, they use the simple name rather
than asking people to repeat the zone:
    https://cloud.google.com/sdk/gcloud/reference/compute/instances/set-machine-type

There is an interesting comparison for AMIs however: in aws-ec2 the AMI id includes the region.
However, I think that is not a fair comparison because the id will always be different in
different regions (or if it is the same it is purely coincidence).

---
As to how `listHardwareProfiles` should behave, I agree that's very tricky. We could return
`n1-standard-1` multiple times, with each instance having a different `hardware.getLocation()`.
But the hardware.getId javadoc is clear that if we did so then the id should include the zone:

    /**
     * 
     * A means to uniquely address this resource within a provider. For example, if the namespace
of
     * a node or image is region based, the id will likely include both the region and the
     * provider-supplied id encoded to avoid collisions.
     * 
     * @return unique id within your account on the provider
     */

And if `hardware.getId()` includes the zone, then for consistency that is what a user should
supply in the template.

An alternative would be to *not* tell the user which locations support which machine-types
when they call `listHardwareProfiles`. That feels consistent with the (ugly) aws-ec2 implementation,
but sub-optimal.

---
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/951#issuecomment-217143429
Mime
View raw message