Thanks for the stacktrace Richard. It looks like the issue is when loading the image cache, so the image selection logic won't be reached, which means there is no possible workaround. Let's fix it as mentioned with Alex suggestion to be able to keep backward compatibility so we can apply the fix to 2.0.x too.
There will be the caveat that the fix will only apply to the image selection logic, but the format of the IDs will change, which could be considered a compatibility breaker. However, when using the jclouds abstraction interfaces everything should be compatible after the fix, so I'd say it should be OK to backport to 2.0.x. On 1 November 2017 at 23:12, Richard Downer <rich...@apache.org> wrote: > Ignasi, > > I've added a stacktrace to > https://issues.apache.org/jira/browse/JCLOUDS-1348. > > Thanks > Richard. > > > On 24 October 2017 at 08:03, Ignasi Barrera <n...@apache.org> wrote: > >> 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. >> >> >> > >>
