[
https://issues.apache.org/jira/browse/JCLOUDS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782115#comment-13782115
]
Adrian Cole commented on JCLOUDS-299:
-------------------------------------
https://github.com/jclouds/jclouds-labs-openstack/pull/34
Implementation notes.
Making this region-independent meant decoupling access to BlobStore and
BlobRequestSigner to a factory w/ a region id.
This implied moving off a lot of the helpers we have, and instead addressing
functionality directly.
The reason is that many blobstore helpers (such as ClearListStrategy) are
circular. IOTW blobstore ends up depending on itself.
The new swift blobstore has only one dependency like this, which is for
deletion, as that code is non-trivial. IMHO, the deleter could be rewritten to
depend on a function as opposed to BlobStore. Nonetheless, here's an example
of how to get an instance of a dependency that needs a blobstore from a
blobstore.
// until we parameterize ClearListStrategy with a factory
this.clearList = baseGraph.createChildInjector(new AbstractModule() {
@Override
protected void configure() {
bind(BlobStore.class).toInstance(RegionScopedSwiftBlobStore.this);
}
}).getInstance(ClearListStrategy.class);
> 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.0
>
> 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.1#6144)
