Leons, thanks for your pointers to the python client. Looking a bit into that I really think we need to change the SoftLayer implementation in jclouds to use the same SoftLayer API that the others client use.
For example, instead of retrieving the ActivePackages and filter for the 'Cloud Server' and extract all the needed information (hardware spec, locations etc) I really do believe that we should have used $SL_API_PUBLIC_ENDPOINT/SoftLayer_Virtual_Guest/getCreateObjectOptions which returns the options available to create a SoftLayer CCI. >From my initial test, this will increase the performances a lot (getActivePackages takes 1m7.422s, while getCreateObjectOptions takes 2.473s!!!) and it should avoid also the issue you are having with the RH image (as it would basically use the same approach that you are using with pyrhon client: get create_options and then createObject) Any thoughts on this? Thanks, Andrea On Tue, Dec 3, 2013 at 8:24 PM, Andrea Turli <[email protected]> wrote: > Hi Leons, > > thanks for your detailed reply. > >> Why does jclouds see image id 13799 as an option but does not see image >> id 22400? >> > This is a very good question but at the moment I can't answer you. Will > try to better understand. > >> What Softlayer API call does jclouds use to compile its list of Softlayer >> images? >> > In terms of jclouds, I think the interested part is not the images but the > hardwareProfile. The current implementation relies on > ProductItem.description so it could fail under certain circumstances, I'm > afraid. > > https://github.com/jclouds/jclouds/blob/master/providers/softlayer/src/main/java/org/jclouds/softlayer/compute/strategy/SoftLayerComputeServiceAdapter.java#L165-L177 > > > which basically starts from the ActivePackages to filter only the "Cloud > Server". > Are you aware of more reliable SoftLayer API that we can reuse also in > jclouds? > > Thanks, > Andrea >
