Duracloud on Openstack with Keystone Authentication

45 views
Skip to first unread message

Bikramjit Singh

unread,
Jul 23, 2014, 2:27:07 PM7/23/14
to duracl...@googlegroups.com
I have a openstack swift cluster with keystone authentication v2. I am trying to connect Duracloud with my swift instance, I found out that current code is only compatible with Auth v1 that's tempAuth. Just want to know that is Duracloud code works with keystone or this functionality is not implemented yet?

Bill Branan

unread,
Jul 23, 2014, 3:12:49 PM7/23/14
to duracl...@googlegroups.com
Hi,

DuraCloud is currently configured to connect to the v1 auth endpoint for both Rackspace and SDSC Cloud. I tested against the v2 endpoint in the past, but have not done so recently. I expect that there may need to be a few tweaks to get it working with v2, but they would likely be minimal. To connect to your own endpoint, you will need to create a StorageProvider implementation which will extend from the OpenStackStorageProvider. I'd recommend forking the code in github (1), adding your StorageProvider implementation (for examples of doing this, see (2) and (3)), and seeing what, if any, parts of the connection code in the OpenStackStorageProvider constructor needs to be overridden in your provider to get the connection to a v2 endpoint working. Once you get the connection going, everything else should work out of the box. Instructions for building DuraCloud code can be found at (4).

best,
Bill Branan
DuraCloud Tech Lead



On Wed, Jul 23, 2014 at 2:27 PM, Bikramjit Singh <bic...@gmail.com> wrote:
I have a openstack swift cluster with keystone authentication v2. I am trying to connect Duracloud with my swift instance, I found out that current code is only compatible with Auth v1 that's tempAuth. Just want to know that is Duracloud code works with keystone or this functionality is not implemented yet?

--
You received this message because you are subscribed to the Google Groups "DuraCloud Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to duracloud-de...@googlegroups.com.
To post to this group, send email to duracl...@googlegroups.com.
Visit this group at http://groups.google.com/group/duracloud-dev.
For more options, visit https://groups.google.com/d/optout.

Bikramjit Singh

unread,
Jul 24, 2014, 12:11:16 PM7/24/14
to duracl...@googlegroups.com
Hi Bill,
Thank you so much for Instructions. I was thinking to do same. I will implement it and let you know.

Thanks once again.

Bikram 

Alan Darnell

unread,
Aug 7, 2014, 4:57:19 PM8/7/14
to duracl...@googlegroups.com
Looks like Apache jclouds knows how to handle either v1 or v2 authentication for Swift.

So I think that the implementation should look pretty much like RackspaceStorageProvider but with authUrl pointing to the Keystone endpoint for OpenStack (ideally passed in through init.properties) and username being in the form TENANT:USERNAME with apiAccessKey being the password.  

This following is from the jclouds site:

      swiftApi = ContextBuilder.newBuilder(provider)
            .endpoint("http://xxx.xxx.xxx.xxx:5000/v2.0/")
            .credentials(identity, credential)
            .modules(modules)
            .buildApi(SwiftApi.class);


Alan

Alan Darnell

unread,
Aug 7, 2014, 5:33:31 PM8/7/14
to duracl...@googlegroups.com
And "swift-keystone" would be the value for provider, or you can use new SwiftKeystoneApiMetadata() instead.

Bill Branan

unread,
Aug 7, 2014, 6:29:23 PM8/7/14
to duracl...@googlegroups.com
Hi Alan,

Thanks for looking into this. It appears like it wouldn't be difficult to test this if you have an OpenStack implementation with a Keystone v2 endpoint to point to try it out on. 

Just a note on the JClouds front, we are stuck using an older version of JClouds in DuraCloud at the moment (a patched 1.5.5 version actually) because of a couple bugs in JClouds. From my tests (one of which is now in the JClouds baseline, https://github.com/jclouds/jclouds/pull/389) these issues have now been resolved, but we are waiting on them to put out a new version of JClouds with the fixes in place. If you want more details you can take a look at https://jira.duraspace.org/browse/DURACLOUD-846 and https://jira.duraspace.org/browse/DURACLOUD-875. There are some changes waiting on a branch (https://github.com/duracloud/duracloud/tree/feature/duracloud-846-jclouds) until the JClouds update is available, at which point we should be able to pull in the latest version and merge in the changes in the branch.

In order to try your proposed changes, you will likely need to update the JClouds version to the latest. The issues I mentioned shouldn't impact your ability to test the authentication connection and do most things. I just wanted you to be aware of why we are currently using an older version.

best,
Bill

Alan Darnell

unread,
Aug 7, 2014, 7:34:58 PM8/7/14
to duracl...@googlegroups.com
Thanks Bill.  

Are you aiming in the end for support of jclouds 1.8?  If so, we'll focus our development on that version.  I think there is a 2.0 in the works but not sure when that is supposed to be released.

Alan

Bill Branan

unread,
Aug 7, 2014, 9:43:32 PM8/7/14
to duracl...@googlegroups.com
Hi Alan,

Yes, currently we're targeting 1.8 since, as you say, it's not clear when the 2.0 version will be available. Based on my communication with the JClouds developers, we can expect the 1.8 release within a month or two.

Bill
Reply all
Reply to author
Forward
0 new messages