You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jclouds.apache.org by Everett Toews <ev...@RACKSPACE.COM> on 2013/07/02 15:40:12 UTC
Re: Conflicting Versions for Rackspace with v1.0 account.
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/>)
Re: Conflicting Versions for Rackspace with v1.0 account.
Posted by Everett Toews <ev...@RACKSPACE.COM>.
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 <ev...@rackspace.com>> 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/>)
Re: Conflicting Versions for Rackspace with v1.0 account.
Posted by Everett Toews <ev...@RACKSPACE.COM>.
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 <ev...@rackspace.com>> 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/>)
Re: Conflicting Versions for Rackspace with v1.0 account.
Posted by Varad Meru <va...@orzota.com>.
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/authHTTP/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
<ev...@rackspace.com>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/authHTTP/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/detailHTTP/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)
>
>