Thanks Ignasi, I will go through the document. If I have any further query or need clarification, whom should I reach out for clarification?
Can you please help me here? Also are we suppose to take up task voluntarily or we are going to be task assigned ? Regards Nishant On Wed, Oct 4, 2017 at 12:27 PM, Ignasi Barrera <n...@apache.org> wrote: > 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 > > >
