Well, since the pluggable ring idea *was* about this as well (I'm pretty sure,
since I proposed it), maybe it's time to talk merkle trees ;)
I'll circle back with notmyname and see what makes sense for breaking up this
discussion into manageable chunks.
Joshua McKenty
Piston Cloud Computing, In
On Tue, May 31, 2011 at 8:37 AM, Rostyslav Slipetskyy
wrote:
> The idea to make ring implementation pluggable seems nice.
> At the same time I am thinking that many developers might not will feel
> comfortable with modifying existing ring structure, since it *works*
> :) Probably, the other viable
for specific accounts.
>
> - Rostik
>
> --
> *From:* Joshua McKenty
> *To:* Rostyslav Slipetskyy
> *Cc:* OpenStack
> *Sent:* Tue, May 31, 2011 1:45:01 AM
> *Subject:* Re: [Openstack] suggestion for data location compliance in
> swift
>
>
Slipetskyy
Cc:OpenStack
Sent:Tue, May 31, 2011 1:45:01 AM
Subject:Re: [Openstack] suggestion for data location compliance in swift
This was one of the use cases that drove the design discussion on decoupling
the
swift ring implementation from the rest of swift (along with supporting
multiple
This was one of the use cases that drove the design discussion on decoupling
the swift ring implementation from the rest of swift (along with supporting
multiple tiers of hardware). See
https://blueprints.launchpad.net/swift/+spec/swift-pluggable-hashing-ring for
the basic proposal, however, an
Some of the data stored in the cloud has legal requirements to be stored
physically within certain geographical boundary (for example within a country).
Currently OpenStack does not allow to impose restrictions on data location.
It looks like zones can be very handy to achieve data location comp
6 matches
Mail list logo
