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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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. > >> > > >
