You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Andrew Phillips (JIRA)" <ji...@apache.org> on 2014/04/15 20:56:36 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 ]

Andrew Phillips updated JCLOUDS-299:
------------------------------------

    Fix Version/s:     (was: 1.7.2)
                   1.7.3

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