[
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)
