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