jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-299) Multi-Region Support for BlobStore
Date Fri, 17 Jan 2014 20:10:19 GMT

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

ASF subversion and git services commented on JCLOUDS-299:
---------------------------------------------------------

Commit 0a8010bef6046798122aef3532ebd78aba8315ce in branch refs/heads/1.7.x from [~jdaggett]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-openstack.git;h=0a8010b ]

JCLOUDS-299: Added copy method to Object API

- Added copy method
- Added CopyObjectException file
- Added SwiftHeaders file
- Updated the Swift error handler
- Added CreateContainerOptions.NONE and updated refs
- Added Region specific configuration for live tests
- Added support for LocationConstants.REGION


> 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.1
>
>   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.5#6160)

Mime
View raw message