Sure we could try to find ways to keep the old behavior, but given Richard's comment that there is an exception inside jclouds (Richard, could you share the complete stacktrace here or in the JIRA issue so we can see the exact point where it fails?), I think a workaround wouldn't work, as the image selection code would not be reached. Once the issue is fixed, using a new format for template ids should be transparent to users, unless they are storing "old" template ids to be used later, which I would not recommend. Is this your use case?
On 23 October 2017 at 18:08, Alex Heneveld <alex.henev...@cloudsoftcorp.com> wrote: > > Can we keep backwards compatibility at image selection time by saying if an > imageId is supplied by caller but isn't found, search for > regionId+":"+imageId? (I'm assuming that the fix changes behaviour so that > jclouds's map of image IDs will now use cloudstack zoneId+":"+templateId as > key, instead of just cloudstack templateId.) > > Best > Alex > > > > On 23/10/2017 17:00, Richard Downer wrote: >> >> On 4 October 2017 at 18:27, 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? >>> >> I've opened JCLOUDS-1348: >> https://issues.apache.org/jira/browse/JCLOUDS-1348 >> >> >>> 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 >>> >> Unfortunately the symptom of the problem is an exception inside jclouds, >> when multiple objects with the same ID are attempted to be added to a hash >> or set (I forget which). >> >> Richard. >> >
