[openstack-dev] [swift] auth migration and user data migration
Clay Gerrard
clay.gerrard at gmail.com
Wed Mar 11 21:10:20 UTC 2015
On Wed, Mar 11, 2015 at 1:16 PM, Weidong Shao <weidongshao at gmail.com> wrote:
>
> the url is encoded in the object hash! This somehow entangles the data
> storage/validity with its account and makes it difficult to migrate the
> data. I guess it is too late to debate on the design of this. Do you know
> the technical reasons for doing this?
>
>
>
Well, yeah - can't see much good coming of trying to "debate" the design :)
The history may well be an aside from the issue at hand, but...
Not having a lookup/indirection layer was a design principle for achieving
the desired scaling properties of Swift. Before Swift some of the
developers that worked on it had built another system that had a lookup
layer and it was a huge pain in the ass after a half billion objects or so
- but as with anything it's not the only way to do it, just trying
something and it seemed to work out.
I'd guess at least some of the justification came from: uri's don't change
- people change them [1].
Without a lookup layer that you can update (i.e. name = resource =>
new_name = resource) - you can either create a new resources that happens
to have the same content of the other and delete the old OR add some custom
namespace redirection to make the resource accessible from another name (a
vanity url middleware comes up from time to time - reseller prefix rewrite
may be as good a use-case as any).
I made sure I was watching the swauth repo [2] - if you open any issues
there I'll try to keep an eye on them. Thanks!
-Clay
1. http://www.w3.org/Provider/Style/URI.html
2. https://github.com/gholt/swauth/issues
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150311/6d7474cb/attachment.html>
More information about the OpenStack-dev
mailing list