John, thanks for the reply. See questions inline.
thanks, Weidong On Mon, Mar 9, 2015 at 8:23 AM John Dickinson <m...@not.mn> wrote: > > > On Mar 9, 2015, at 9:46 AM, Weidong Shao <weidongs...@gmail.com> wrote: > > > > hi, > > > > I have a standalone swift cluster with swauth as the auth module. By > standalone, I mean the cluster is not in the context of OpenStack, or > keystone server. > > That's completely fine (and not uncommon at all). > > > > > Now I have moved ACL logic to application level and decided to have all > data in swift under one user account. I have a few questions on this change: > > > > 1) is it possible to migrate swauth to the tempAuth? (assuming tempauth > will be supported in newer swift versions). > > Why? > > Yes, tempauth is still in swift. It's mostly there for testing. I wouldn't > recommend using it in production. > > I noticed swauth project is not actively maintained. In my local testing, swauth did not work after I upgraded swift to latest. I want to migrate off swauth. What are the auth alternative beside tempauth? > > > > > 2) Is there a way to migrate data associated with one user account to > another user? > > "user account" Do you mean the identity or the account part of the Swift > URL? If the former, then changing the reference in the auth system should > probably work. If the latter, then you'll need to copy from one account to > the other (Swift supports account-to-account server-side copy). > > > I think it is for both. The former applies because I plan to change auth, I hope that all the data access in intact with a auth url change, so that I do not need to migrate the data after the auth change. On account-to-account server-side copy, is there an operation that is similar to "mv"? i.e., I want the data associated with an account to assume ownership of a new account, but I do not want to copy the actual data on the disks. > > > > Thanks, > > Weidong > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev