On 17 Feb 2012, at 06:12, Pete Zaitcev wrote: >> - A S3Token middleware which is based on Akira version with some fixes. > Yeah, that looks beautiful... Unfortunately the back-end > inherits the old problem: it authorizes against EC2 credentials > instead of Swift credentials. The result is, if two applications > A and B use different access methods, CF and S3, to the same account, > they do not see each other's objects. It happens because the storage > URL returned by Keystone differs for them, as far as I can discern.
This is actually supported as mentioned in my temporary doc[1] see the transcript here : http://pastie.org/3401911 this made of from a fresh devstack with a few tweaks to the configurations. I plan to add this to devstack but I am waiting first for some of my other review to get approved to push those changes and be able to get rid of swift-keystone2 for good. >> S3token middleware: https://review.openstack.org/#change,3910 >> Swift token middleware: https://review.openstack.org/#change,3911 > Do you still want reviews on these, after the merge of redux? This has been merged to keystone master, feel free to review the one the add reseller admin support : https://review.openstack.org/#change,4234 and the doc update : https://review.openstack.org/#change,4233 The reseller admin will allow us ultimately to have swift acting as a nova-objectstore for nova. I have more plans for the middleware, I'd like to get the compressive tempauth testsuite running on swiftauth with almost no modifications and add along the way anonymous user object access via ACL. Let me know if you have questions. Cheers, Chmouel. PS: readding openstack@ as this may be useful for everyone. [1] http://p.chmouel.com/swift-keystonelight-s3.txt
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
