Hi Varad, I was able to reproduce your issue but the real problem isn't the v1 REST call.
The real problem is that the override overrides.setProperty(KeystoneProperties.CREDENTIAL_TYPE, CredentialTypes.PASSWORD_CREDENTIALS); Doesn't work with the First Gen provider in jclouds and there are no plans to support it. It's sending your password but in the request body format that is used for the API key. If you drop the override and just use your API key, everything will work fine. You can find your API key by going to the Cloud Control Panel [1] > top right corner > Settings & Contacts > API Key. Regards, Everett [1] https://mycloud.rackspace.com On Jul 2, 2013, at 8:28 PM, Everett Toews wrote: Okay. I'll try this out tomorrow. Everett On Jul 2, 2013, at 1:24 PM, Varad Meru wrote: Thanks Everett for your questions, I resolved the Case 2: Creating Next Generation Servers, as it was a policy issue. You are correct, it was an issue with sub-user policy. As for Case 1: Creating first generation servers: Yes, its better to focus on Next generation stack. But to resolve the error, IMO, its a small change in jclouds. for first generation providers, jclouds internally authenticates the user, with v1 REST call, As you can see, Caused by: org.jclouds.http.HttpResponseException: request: POST https://auth.api.rackspacecloud.com/v1.1/auth HTTP/1.1 [{"credentials":{"username":"***","key":"***"}}] failed with response: HTTP/1.1 401 Unauthorized at org.jclouds.cloudservers.handlers.ParseCloudServersErrorFromHttpResponse.handleError(ParseCloudServersErrorFromHttpResponse.java:51) ... 52 more But as per the documentation from Rackspace, it should make call to v2 REST call. Thanks and Regards, Varad On Tue, Jul 2, 2013 at 7:10 PM, Everett Toews <[email protected]<mailto:[email protected]>> wrote: Hi Varad, To start, a few questions about your problem. 1. Are you still having it or did you find a solution? 2. Do you really need to use First Gen servers or can you use only Next Gen servers? Any time there's a new version of something, it's usually a safe bet the old version will be removed at some point even if there isn't a specific timeline for it. Using only Next Gen servers would definitely simplify things. 3. In Case 2 with the Next Gen servers, is the user you're authenticating with a sub user? That's a rare error message and, AFAIK, only occurs for sub users. Thanks, Everett On Jun 26, 2013, at 8:00 AM, Varad Meru wrote: Hi, I am trying to develop an application which would auto-provision nodes on Rackspace compute cloud. But the versions (First-Gen and Next-Gen) are conflicting. I am facing 2 issues - 1. If we use first generation provider metadata or name (cloudserver-us), the authentication fails. 2. If we use next generation provider metadata or name (rackspace-cloudserver-us), authentication works, but the internal query is hitting the cloudServerOpenStack module, and not the cloudServers module of Rackspace. Explanation - Authentication with Curl, Explanation of Case 1, Explanation of case 2. (with relevant code snippets and comments) 1. Authentication from Curl, and endpoints - After requesting the authentication from Rackspace using the curl requests (From http://docs.rackspace.com/servers/api/v1.0/cs-devguide/content/auth.html), I got a response with endpoint details in it. - Request curl -s https://identity.api.rackspacecloud.com/v2.0/tokens -X 'POST' \ -d '{"auth":{"passwordCredentials":{"username":"***", "password":"***"}}}' \ -H "Content-Type: application/json" | python -m json.tool Note: The v1.0 documentation refers to a v2.0 authentication method. - Response ... { "endpoints": [ { "publicURL": "https://servers.api.rackspacecloud.com/v1.0/825653";, "tenantId": "825653", "versionId": "1.0", "versionInfo": "https://servers.api.rackspacecloud.com/v1.0";, "versionList": "https://servers.api.rackspacecloud.com/"; } ], "name": "cloudServers", "type": "compute" } } ... { "endpoints": [ ... { "publicURL": "https://ord.servers.api.rackspacecloud.com/v2/825653";, "region": "ORD", "tenantId": "825653", "versionId": "2", "versionInfo": "https://ord.servers.api.rackspacecloud.com/v2";, "versionList": "https://ord.servers.api.rackspacecloud.com/"; }, ... ], "name": "cloudServersOpenStack", "type": "compute" }, } Common Scenario Code Snippets - private Properties overrides = null; overrides.setProperty(KeystoneProperties.CREDENTIAL_TYPE, CredentialTypes.PASSWORD_CREDENTIALS); ... // FirstGen ProviderMetadata CloudServersUSProviderMetadata firstGenProviderMetadata = CloudServersUSProviderMetadata.builder().build(); // NextGen ProviderMetadata org.jclouds.rackspace.cloudservers.us.CloudServersUSProviderMetadata nextGenProviderMetadata = org.jclouds.rackspace.cloudservers.us.CloudServersUSProviderMetadata.builder().build(); ... // Create Nodes in Group Set<? extends NodeMetadata> nodes = compute.createNodesInGroup(NAME, 1, template); 2. Case 1 - If I keep the ProviderMetadata as first gen, i.e. ContextBuilder builder = ContextBuilder.newBuilder(firstGenProviderMetadata).credentials(USERNAME, PASSWORD).overrides(overrides); jclouds internally still uses v1.1 method to authenticate the user, as seen in the Exception stack. (Username, password removed). Caused by: org.jclouds.http.HttpResponseException: request: POST https://auth.api.rackspacecloud.com/v1.1/auth HTTP/1.1 [{"credentials":{"username":"***","key":"***"}}] failed with response: HTTP/1.1 401 Unauthorized at org.jclouds.cloudservers.handlers.ParseCloudServersErrorFromHttpResponse.handleError(ParseCloudServersErrorFromHttpResponse.java:51) ... 52 more But as explained above, the documentation says authentication would now use a v2 API. 3. Case 2 - If I keep the ProviderMetadata as next gen, i.e. ContextBuilder builder = ContextBuilder.newBuilder(nextGenProviderMetadata).credentials(USERNAME, PASSWORD).overrides(overrides); This causes the internal exception of policy. Caused by: org.jclouds.http.HttpResponseException: command: GET https://ord.servers.api.rackspacecloud.com/v2/825653/servers/detail HTTP/1.1 failed with response: HTTP/1.1 403 Forbidden; content: [{"forbidden": {"message": "Policy doesn't allow compute:get_all to be performed.", "code": 403}}] at org.jclouds.openstack.nova.v2_0.handlers.NovaErrorHandler.handleError(NovaErrorHandler.java:83) ... 24 more I verified this error with curl request too - Varads-MacBook:~ varadmeru$ curl -s https://ord.servers.api.rackspacecloud.com/v2/825653/servers/detail \ > -H "X-Auth-Token:8a320075315a47ca81e1ac70f1fa9bf9" | python -m json.tool { "forbidden": { "code": 403, "message": "Policy doesn't allow compute:get_all to be performed." } } As seen above, this URL is for the CloudServersOpenStack endpoint, and not to the cloudServers end-point, in which we want to create nodes. Please let me know a solution of 1 of the cases. I am also looking into the code, for finding the relevant code snippets. Thanks in advance. Regards, Varad ----------------- Varad Meru Software Development Engineer, Orzota, Inc. (www.orzota.com<http://www.orzota.com/>)
