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

Reply via email to