Hi! Thanks for the detailed report, Richard.
It is indeed an issue and I don't recall it to be already filed in JIRA so please, would you mind opening it? The solution, as you say, would be to encode the zone in the image id as we do in other providers. We can keep the actual unencoded form in the "providerId" field, which is the "real" id in the provider. I don't see a way of keeping backward compatibility, but it should be a workaround, depending on the exact problem you're facing. If the problem is just about the ComputeService selecting the wrong image, you could use the "imageChooser" [1] option of the TemplateBuilder. With that option you can provide a function that, given the list of images that match the given criteria, selects the best one. You could, instead of directly using the "imageId" options, use other filters to limit the search and then use a custom chooser to get the right image taking into account the image location. FWIW, this [2] is the function that transforms a CloudStack Template into a jclouds Image. Kumar, you're very welcome to contribute! You can start by reading this: https://cwiki.apache.org/confluence/display/JCLOUDS/How+to+Contribute The fix should not be difficult. It should be just about changing the mentioned function to return the zone and the template id encoded in the Image ID field. We often do this by using helper classes, such as this one in the DigitalOcean [3] provider). Once that function is updated and jclouds returns Image objects with those encoded IDs, you'll probably have to update the compute service adapter [4] to take that into account and parse the image ID where necessary. You might also need to change other classes in the compute package [5]. Once done, you may also want to run the live tests [6] against a CloudStack environment to make sure everything is working as expected. Feel free to ask here or in our Freenode IRC channel any doubts you may have and we'll be happy to help! I. [1] http://jclouds.apache.org/reference/javadoc/2.0.x/org/jclouds/compute/domain/TemplateBuilder.html#imageChooser(com.google.common.base.Function) [2] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/functions/TemplateToImage.java [3] https://github.com/jclouds/jclouds/blob/master/providers/digitalocean2/src/main/java/org/jclouds/digitalocean2/compute/internal/ImageInRegion.java [4] https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute/strategy/CloudStackComputeServiceAdapter.java [5] https://github.com/jclouds/jclouds/tree/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/compute [6] https://cwiki.apache.org/confluence/display/JCLOUDS/Testing On 3 October 2017 at 23:43, Kumar Nishant <knishan...@gmail.com> wrote: > Hi Team, > I would like to contribute for Cloud and I am new to this platform. Please > guide me and suggest how can I start making the contribution. > > Thanks > Nishant > > > On Oct 3, 2017 5:30 AM, "Richard Downer" <rich...@apache.org> wrote: > > All, > > 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 [1]. Of > particular note is the message [2]: > > "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 <serg...@hotmail.com>) > > This means that a jclouds change is required to be compatible with > CloudStacks that contain zone-to-zone copied templates. Combining the > region ID and image ID is something that jclouds already does for several > other clouds, so technically this should not be difficult. > > However, I'm concerned there might be a backward compatibility issue if we > simply do this - existing users who use jclouds and reference plain > template IDs would be broken if templates IDs were now prefixed by the zone > ID. > > Is there an issue here and if so how should it be handled? > > Richard. > > > [1] > https://lists.apache.org/thread.html/f93385bbb0e04d7af9b80e7f8f90f9 > 57cb8633144dd2b282cde7d3fc@%3Cusers.cloudstack.apache.org%3E > [2] > https://lists.apache.org/thread.html/8d99f7462618438a6a3bcbb3fe7e73 > 6c5632db7d07de449f610b68c2@%3Cusers.cloudstack.apache.org%3E >
