Re: Composite blob store and Overlay blob store proposals

Hi Amit, > Storage class should be included if it can be, so long as it serves a > purpose. I’m not sure I’m seeing the purpose yet. > > Why I added "storage class" as separate from "priority" was to highlight some DataStore(s) would need special handling for reads/writes for e.g. a read from

Re: Composite blob store and Overlay blob store proposals

Hi Amit, On July 31, 2017 at 4:49:37 AM, Amit Jain (am...@ieee.org) wrote: With this in mind can't we just conceptually have a Composite DataStore (Not drilling down to interface/class hierarchy and API yet) which can then support the following: * User provided "type" of blob to influence the

Re: Composite blob store and Overlay blob store proposals

Hi all, Thanks for the feedback, please keep it coming. After considering what’s been said I agree that merging the two concepts to one is less confusing and a better approach. Essentially the idea is to use the overlay concept for request resolution (which eventually checks every delegate,

Re: Composite blob store and Overlay blob store proposals

Hi, I read the proposals and I have a comment wrt the Overlay/Composite DataStores at a high level. IIUC, these 2 are similar except that the Overlay could have duplicated binaries right? After reading the details around the two it seems to me Overlay is sort of a super set of the 2 and whether

Re: Composite blob store and Overlay blob store proposals

2017-07-26 17:38 GMT+02:00 Matt Ryan : > Hi Arek, > > >> Regarding CompositeBlobStore -- what if customer changes the storage >> rules in the meantime (refers also to Curation section). This will >> result in the new layout for writes but binaries won't be read >> correctly, am I

Fwd: Composite blob store and Overlay blob store proposals

Hi, 2017-07-26 17:33 GMT+02:00 Matt Ryan : > >> If you could configure priority for read in the following order: {FBS, >> S3DS} but for writes in inverse order {S3DS, FBS} then this will >> almost satisfy any DataStore migration scenarios (except the need to >> transfer content

Re: Composite blob store and Overlay blob store proposals

Hi Arek, Regarding CompositeBlobStore -- what if customer changes the storage rules in the meantime (refers also to Curation section). This will result in the new layout for writes but binaries won't be read correctly, am I right? I guess this could be resolved by nesting: CompositeBlobStore

Re: Composite blob store and Overlay blob store proposals

Hi Arek, In the wiki there is no precise IMHO statement about write: > The overlay blob store fulfills write requests by attempting to write to each delegate in priority order. Once a write is successfully satisfied by a delegate, the result of the delegate write is returned as the result of

Re: Composite blob store and Overlay blob store proposals

2017-07-26 11:02 GMT+02:00 Arek Kita : > S3DataStore ---> AmazonDataStore oops, should be: S3DataStore ---> AzureDataStore

Re: Composite blob store and Overlay blob store proposals

Hi Matt, In the wiki there is no precise IMHO statement about write: > The overlay blob store fulfills write requests by attempting to write to each > delegate in priority order. Once a write is successfully satisfied by a > delegate, the result of the delegate write is returned as the result

Composite blob store and Overlay blob store proposals

Hi oak-dev, I’ve written up some proposals on the wiki for blob stores that can reference multiple blob storage locations. Both act as a single logical blob store to Oak and can be treated as a single blob store. Both have at least two “delegate” blob stores managed by the primary blob store.