You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Adrian Cole (JIRA)" <ji...@apache.org> on 2013/09/27 04:38:03 UTC
[jira] [Updated] (JCLOUDS-299) Multi-Region Support for BlobStore
[ https://issues.apache.org/jira/browse/JCLOUDS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adrian Cole updated JCLOUDS-299:
--------------------------------
Description:
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
was:
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
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira