[
https://issues.apache.org/jira/browse/JCLOUDS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959202#comment-13959202
]
ASF subversion and git services commented on JCLOUDS-299:
---------------------------------------------------------
Commit cc81af6ae9ffdbe583c4053d50afe4891ff23525 in jclouds-labs-openstack's
branch refs/heads/1.7.x from [~jdaggett]
[
https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-openstack.git;h=cc81af6 ]
Backport of OpenStack Swift/Rackspace Cloud Files as described in JCLOUDS-299
and JCLOUDS-423
> Multi-Region Support for BlobStore
> ----------------------------------
>
> Key: JCLOUDS-299
> URL: https://issues.apache.org/jira/browse/JCLOUDS-299
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
> Reporter: Adrian Cole
> Assignee: Adrian Cole
> Fix For: 1.7.2
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Currently, the BlobStoreContext api is only effective for a specific region.
> This has some benefits, such as knowing failure cases only apply to one
> region. The way to achieve this is in swift-keystone is to provide a context
> property of a well-known region id. This was introduced in
> https://issues.apache.org/jira/browse/JCLOUDS-126
> For effective multi-region apps, we need to both expose which regions are
> available, and also continue isolating a BlobStore to a specific one. Using
> this model, users can have predictable performance (ex. one BlobStore command
> won't cross regions), and isolation (one down region won't affect the
> BlobStore in use).
> The style of exposing an api scoped to region is also something we've
> practiced for well over a year, at the provider api level.
> ex. SwiftApi.getObjectApiForRegion("foo") style is commonplace now, even if
> not yet in the "View" interfaces such as BlobStore.
> During the last planning meeting, Maginatics (via andrew gaul) raised
> supporting multiple regions in BlobStore is becoming a must have. Users need
> to interact with multiple regions within Rackspace and OpenStack, for
> example, and these users may not know the magic region ids, nor desire
> maintaining a separate context for each.
> This issue introduces a design that takes directly from the 'provider api"
> practice of get*ApiForRegion("foo"), applied it to BlobStore, specifically
> the word "region" as that has a fairly common understanding across BlobStore
> providers.
> Ex.
> BlobStoreContext ctx = ...
> // new command
> // note we aren't propagating the rarely useful Location object, and instead
> dealing w/ Strings
> // also note this is *before* you get a blobstore instance, hinting that this
> is a discovery command
> Set<String> regionIds = ctx.configuredRegions();
> // maintain current behaviour, which defers to defaults.
> BlobStore defaultBS = ctx.getBlobStore();
> // new command
> // isolated to a specific region and will not make calls across multiple
> endpoints
> BlobStore defaultBS = ctx.blobStoreInRegion("foo");
> Note the style above is opinionated a bit. For example, we aren't following
> the javabeans practice of putting "get" in front of everything. See "how to
> write a method" http://vimeo.com/74316116
--
This message was sent by Atlassian JIRA
(v6.2#6252)
