jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shri Javadekar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-645) Incorrect endpoint url chosen for default region of HPCloud Object Storage
Date Fri, 01 Aug 2014 17:59:41 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082626#comment-14082626
] 

Shri Javadekar commented on JCLOUDS-645:
----------------------------------------

I agree with the larger point about arbitrary endpoint resolution. And maybe we should make
it mandatory for users to specify a region. Would be great if we give prior notice about it
though. One other way to do this would be to use a specific region name as the default rather
than first or last index into an array.

People have accounts with cloud providers. They may not be concerned about where (what region)
the data gets stored. If they were concerned about the region, they would've already set the
region. For the default case, if suddenly after an upgrade they stop having access to their
data because a different region was getting selected would be a bad user experience. Neways,
let's have this discussion outside of this bug.

To summarize what we have here:

In jclouds 1.7.x, a user was required to set jclouds.region to "region-b.geo-1" *and* set
the apiVersion to "1" to work with region-b Ideally one wouldn't have to specify the apiVersion
but for whatever reason HPCloud Object Storage has set the version to "1" instead of "1.0".
A user only had to set jclouds.region to "region-a.geo-1" (no need to set apiVersion) or not
specify any region to work with region-a. This worked because the default apiVersion was "1.0".

In jclouds 1.8.0, a user can set jclouds.region to "region-b.geo-1" to work with region-b
or "region-a.geo-1" to work with region-a. The user never has to specify the apiVersion. Not
specifying any value for jclouds.region results in "region-b" getting selected. This happens
because the apiVersion is null and "region-b" is the last index in the array.

If jclouds.region is null, both the above approaches suffer from a problem. jclouds 1.7.x
breaks if the Keystone endpoint of HPCloud Object Storage changes their service catalog to
add another region with apiVersion "1.0". jclouds 1.8.0 breaks if the Keystone endpoint in
HPCloud Object Storage add another region to their service catalog.

If we want to continue with what we have, I'll run some tests explicitly setting the jclouds.region
and jclouds.apiVersion to make sure everything works.

> Incorrect endpoint url chosen for default region of HPCloud Object Storage
> --------------------------------------------------------------------------
>
>                 Key: JCLOUDS-645
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-645
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-blobstore
>    Affects Versions: 1.8.0
>            Reporter: Shri Javadekar
>            Assignee: Chris Custine
>             Fix For: 1.8.0
>
>
> JClouds seems to be choosing the wrong endpoint from the service catalog returned by
HPCloud Object Storage.
> From what I see there are two endpoints returned in the Object Storage part of the service
catalog.
> D 07-31 13:21:22.122 pool-1-thread-1 jclouds.wire:59 |::] << "          "publicURL":
"https:\/\/region-a.geo-1.objects.hpcloudsvc.com\/v1\/53176293441764",[\n]"
> D 07-31 13:21:22.124 pool-1-thread-1 jclouds.wire:59 |::] << "          "publicURL":
"https:\/\/region-b.geo-1.objects.hpcloudsvc.com\/v1\/53176293441764",[\n]"
> I do not have any region configured.
> With 1.7.3, the first url was getting used and my tests were succeeding. However, with
1.8.0 the second url get's chosen and my tests failed with a "404 Not Found" error.
> See this for more details: http://pastie.org/private/yzxbnvxwidajalcucwflwa



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message