[
https://issues.apache.org/jira/browse/JCLOUDS-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132576#comment-15132576
]
Chava Jurado edited comment on JCLOUDS-1068 at 2/4/16 4:57 PM:
---------------------------------------------------------------
[~andreaturli] Thanks for your help. To your last point in your last comment,
everything you are suggesting is correct in 1.9.1. I can just drop in the
global identifier of a private image and it works. It returns the private
image as advertised. When switching to 1.9.2 it no longer works. Specifying
UUID's of private images do not result in the object being that private image.
It instead returns a public image.
When inspecting the Softlayer REST requests and responses via the
SLF4JLoggingModule the results are the same in 1.9.1 and 1.9.2.
{code}
https://api.softlayer.com/rest/v3/SoftLayer_Virtual_Guest_Block_Device_Template_Group/de305d54-75b4-431b-adb2-eb6b9e546014/getObject?objectMask=children.blockDevices.diskImage.softwareReferences.softwareDescription
{code}
{code}
"{"accountId":XXXXXX,"createDate":"2016-01-19T16:07:32-06:00","id":655319,"name":"03c0a96d46e57dac5912ec","note":"03c0a96d46e57dac5912ec","parentId":null,"publicFlag":0,"statusId":1,"
... "globalIdentifier":"de305d54-75b4-431b-adb2-eb6b9e546014"}"
{code}
It appears the after jclouds gets the SL response then something in the logic
changes the results. Since global ids for public images work (I was able to
confirm getting the CENTOS by UUID as well) it seems like the results from
Softlayer are maybe checked against a list of public images? If it finds no
correlation so it discards the SL response and substitutes a public image of
the same OS family, maybe?
was (Author: chjurado):
[~andreaturli] Thanks for your help. To your last point in your last comment,
everything you are suggesting is correct in 1.9.1. I can just drop in the
global identifier of a private image and it works. It returns the private
image as advertised. When switching to 1.9.2 it no longer works. Specifying
UUID's of private images do not result in the object being that private image.
It instead returns a public image.
When inspecting the Softlayer REST requests and responses via the
SLF4JLoggingModule the results are the same in 1.9.1 and 1.9.2.
{code}
https://api.softlayer.com/rest/v3/SoftLayer_Virtual_Guest_Block_Device_Template_Group/de305d54-75b4-431b-adb2-eb6b9e546014/getObject?objectMask=children.blockDevices.diskImage.softwareReferences.softwareDescription
{code}
{code}
"{"accountId":XXXXXX,"createDate":"2016-01-19T16:07:32-06:00","id":655319,"name":"03c0a96d46e57dac5912ec","note":"03c0a96d46e57dac5912ec","parentId":null,"publicFlag":0,"statusId":1,"
... "globalIdentifier":"de305d54-75b4-431b-adb2-eb6b9e546014"}"
{code}
It appears the after jclouds gets the SL response that something in the logic
changes the results. Since global ids for public images work (I was able to
confirm getting the CENTOS by UUID as well) it seems like the results from
Softlayer are maybe checked against a list of public images? If it finds no
correlation so it discards the SL response and substitutes a public image of
the same OS family, maybe?
> Softlayer context.getComputeService().getImage() does not work in 1.9.2 like
> it did in 1.9.1
> --------------------------------------------------------------------------------------------
>
> Key: JCLOUDS-1068
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1068
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
> Affects Versions: 1.9.2
> Reporter: Chava Jurado
> Priority: Minor
> Labels: softlayer
>
> In 1.9.1 the following code can retrieve a private image by global id, but in
> 1.9.2 it returns UBUNTU_14_64.
> {code:title=Softlayer Example|borderStyle=solid}
> import java.util.Properties;
> import org.jclouds.ContextBuilder;
> import org.jclouds.compute.ComputeServiceContext;
> import org.jclouds.compute.domain.Image;
> import org.jclouds.logging.slf4j.config.SLF4JLoggingModule;
> import com.google.common.collect.ImmutableSet;
> import com.google.inject.Module;
> public class SoftlayerExample {
> public static void main(String[] args) {
> String identity = "SLxxxxxx"; //accountName
> String identityCredential = ""; //apiKey
> String imageId = ""; //globalIdentifier
> Properties overrides = new Properties();
> ImmutableSet<Module> modules = ImmutableSet
> .<Module> of(new SLF4JLoggingModule());
> ComputeServiceContext context =
> ContextBuilder.newBuilder("softlayer")
> .credentials(identity,
> identityCredential).overrides(overrides)
>
> .modules(modules).buildView(ComputeServiceContext.class);
> Image image = context.getComputeService().getImage(imageId);
> System.out.println(image.getId());
> if (!image.getId().matches(imageId)) {
> System.out.println("No workie in 1.9.2 :(");
> }
> }
> }
> {code}
> Looking at the API calls returned by Softlayer in 1.9.1 and 1.9.2, they are
> identical. Both are able to get the information from softlayer, but for some
> reason the object returned in 1.9.2 is a base ubuntu image.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
