jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Cole (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-299) Multi-Region Support for BlobStore
Date Tue, 01 Oct 2013 15:04:24 GMT

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

Adrian Cole commented on JCLOUDS-299:
-------------------------------------

I'd prefer to deprecate the old one, as well many methods on BlobStore :),

but lets wait until folks test this interface in swift before changing the
global BlobStore?


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

Mime
View raw message