I've been investigating a problem that a client reported - they were trying to use jclouds with their client's CloudStack instance but were hitting problems caused by the result of the CloudStack `listTemplates` options returning members with duplicated ID fields.
On inspection of the wire logs, it seemed that some templates were duplicated multiple times but in different zones. All of the fields were the same, except for the zone ID and name.
These were not "cross zone" templates, which is an option where CloudStack automatically copies a template to every zone. jclouds detects and handles those, by collapsing all templates with the same ID and the `crossZones` paramter set to true, down to a single global-scoped image.
Instead, it would appear that CloudStack has an option to copy a template to another zone. It's not a global template, it only goes to selective zones. But it does preserve the template ID - so you can end up with multiple region-scoped images that have the same ID.
My discussion on the Apache CloudStack mailing list is at: https://lists.apache.org/thread.html/f93385bbb0e04d7af9b80e7f8f90f957cb8633144dd2b282cde7d3fc@%3Cusers.cloudstack.apache.org%3E
Of particular note is this message: https://lists.apache.org/thread.html/8d99f7462618438a6a3bcbb3fe7e736c5632db7d07de449f610b68c2@%3Cusers.cloudstack.apache.org%3E
"As long as template is copied from zone to zone it will present with duplicate ID. This is by design. crossZone parameter is to indicate to auto replicate template across all available zone on template creation. To put it differently only combination of template ID and zone ID is a primary key for template querying."
(From: Sergey Levitskiy <firstname.lastname@example.org>)
This implies that jclouds must change its behaviour to always assume that image IDs are not globally unique, perhaps by - as Sergey suggests - incorporating the zone ID into jclouds' image ID.