Context creation best practices

[Jonathan]

What are the best practices for creating ComputeServiceContext instances? Can they be cached indefinitely or do they need to be created and closed for each request? Similarly for RestContext instances - can these be cached? One concern with caching is auth tokens becoming stale...

What are the best practices for creating and using the various contexts?

Cheers,

Jonathan

[Adrian Cole]

Hi, Jonathan.

The context objects were made for long-lived JVMs.  re-authentication, cache expiration, etc are builtin.  It is always better to reuse than create new, where-ever you can.

-A

--
You received this message because you are subscribed to the Google Groups "jclouds" group.
To view this discussion on the web visit https://groups.google.com/d/msg/jclouds/-/JPt51IzJYx0J.
To post to this group, send email to jcl...@googlegroups.com.
To unsubscribe from this group, send email to jclouds+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jclouds?hl=en.

[Chris Strand]

Hi Jonathon,

In another thread a couple of months ago the time taken to create a context was discussed. If context creation time is an issue for you, don't use the provider ID/name to create the context, look it up by type instead. Adrian explained it a bit more here: https://groups.google.com/d/topic/jclouds/XococHWwx8c/discussion

Chris

[Jonathan]

Hey Adrian,

Do you have any tips for how we can verify that auth token expiration is or isn't working as expected? We're hitting 401s after running with the same ComputeServiceContext for 24 hours, which coincides with expected auth token expiration. Grabbing a new ComputeServiceContext has things working fine again, but ideally this would be handled internally by JClouds, as you mentioned. Any suggestions?

Cheers,

Jonathan

[Adrian Cole]

Which provider is this, and do you happen to have an http log? With that, we can make a test case.

-A

To view this discussion on the web visit https://groups.google.com/d/msg/jclouds/-/C8Iq-4iAk7wJ.

[Jonathan]

This is on HP's cloud. I don't have any HTTP logs yet, but I can capture some. What logging should I enable and what duration do you want captured?

Jonathan

[Adrian Cole]

Hi, Jonathan.

Can you set jclouds.headers and jclouds.wire to debug?  When the exception happens, include the requests directly before and after.

Thanks!
-A

To view this discussion on the web visit https://groups.google.com/d/msg/jclouds/-/xc7XUclua4IJ.

[Everett Toews]

Hi Jonathan,

I recently had to dive into this particular bit of code to check that it works for the Rackspace Open Cloud and what I discovered might help you a bit too.

My test case happened within a single run of a JVM:

1. List servers
2. Pause for input (here I waited over 24 hours and then pressed Enter)
3. List servers

With logging enabled, I could see that at #1 jclouds got a token. When #3 happened, I could see that jclouds re-authed, got a new token, and kept ticking along happily.

So jclouds did the right thing, but how? Digging a bit deeper, this is what I found.

1. CloudServersUSProviderMetadata adds the CloudIdentityAuthenticationModule as one of its default modules
2. The CloudIdentityAuthenticationModule extends the KeystoneAuthenticationModule
3. KeystoneAuthenticationModule.configure() binds the HttpRetryHandler to the RetryOnRenew class
4. When a request with an invalid token happens, ultimately BaseHttpCommandExecutorService.shouldContinue() calls RetryOnRenew.shouldRetryRequest(), which invalidates the cached token
5. BaseHttpCommandExecutorService.call() tries again

If anyone knows of something important I've missed or if I'm just flat out wrong somewhere in the above, please let me know.

I assume you could do something similar in the HP Cloud Provider Metadata. If you're having issues with logging, you might want to check out my post on http://blog.phymata.com/2012/08/18/logging-in-jclouds/

Regards,

Everett

[Adrian Cole]

You rock, Everett.

[Jonathan]

Good stuff Everett - Thanks! Will follow up later today once I've passed the 24 hour mark.

Jonathan

[Jonathan]

Hey Adrian - Here are the logs including 2 requests before the 401s hit and 2 after. Same ComputeServiceContext and everything after is all 401s:

DEBUG [2012-08-29 06:49:52,269] jclouds.headers: >> GET https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/38355481723476/servers/449985 HTTP/1.1

DEBUG [2012-08-29 06:49:52,269] jclouds.headers: >> Accept: application/json

DEBUG [2012-08-29 06:49:52,269] jclouds.headers: >> X-Auth-Token: HPAuth_5034aee129c0e12c0726c35c

DEBUG [2012-08-29 06:49:54,493] jclouds.headers: << HTTP/1.1 200 OK

DEBUG [2012-08-29 06:49:54,493] jclouds.headers: << Date: Wed, 29 Aug 2012 08:08:39 GMT

DEBUG [2012-08-29 06:49:54,493] jclouds.headers: << Content-Type: application/json; charset=UTF-8

DEBUG [2012-08-29 06:49:54,494] jclouds.headers: << Content-Length: 1302

DEBUG [2012-08-29 06:49:54,495] jclouds.wire: << "{"server": {"status": "ACTIVE", "updated": "2012-08-29T08:07:46Z", "hostId": "db011daabb9af2702c9f665b02ce1e329420101a6f39096577ff36f7", "user_id": "67969486360176", "name": "125bdf0b-75e8-4607-ad08-4519efb361c3", "links": [{"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/38355481723476/servers/449985", "rel": "self"}, {"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/38355481723476/servers/449985", "rel": "bookmark"}], "addresses": {"private": [{"version": 4, "addr": "10.7.116.233"}, {"version": 4, "addr": "15.185.170.145"}]}, "tenant_id": "38355481723XXX", "image": {"id": "44744", "links": [{"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/38355481723476/images/44744", "rel": "bookmark"}]}, "created": "2012-08-29T08:06:48Z", "uuid": "1ea14c95-f14d-47b0-80e8-5ac797de9c19", "accessIPv4": "", "accessIPv6": "", "key_name": "service-instance", "progress": 100, "flavor": {"id": "104", "links": [{"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/38355481723476/flavors/104", "rel": "bookmark"}]}, "config_drive": "", "id": 449985, "security_groups": [{"name": "service-instance", "links": [{"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/38355481723476/os-security-groups/3268", "rel": "bookmark"}], "id": 3268}], "metadata": {}}}"

DEBUG [2012-08-29 06:59:03,964] jclouds.headers: >> GET https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/38355481723476/servers/450003 HTTP/1.1

DEBUG [2012-08-29 06:59:03,964] jclouds.headers: >> Accept: application/json

DEBUG [2012-08-29 06:59:03,965] jclouds.headers: >> X-Auth-Token: HPAuth_5034aee129c0e12c0726c35c

DEBUG [2012-08-29 06:59:06,185] jclouds.headers: << HTTP/1.1 200 OK

DEBUG [2012-08-29 06:59:06,186] jclouds.headers: << Date: Wed, 29 Aug 2012 08:17:50 GMT

DEBUG [2012-08-29 06:59:06,186] jclouds.headers: << Cneonction: close

DEBUG [2012-08-29 06:59:06,186] jclouds.headers: << Content-Type: application/json; charset=UTF-8

DEBUG [2012-08-29 06:59:06,186] jclouds.headers: << Content-Length: 1302

DEBUG [2012-08-29 06:59:06,187] jclouds.wire: << "{"server": {"status": "ACTIVE", "updated": "2012-08-29T08:17:00Z", "hostId": "7e85fcbe4c373c976fcb38be162f3864651711d33c2f18e9cf21716e", "user_id": "67969486360176", "name": "2b00f064-2424-4d00-915b-b103c18891f8", "links": [{"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/38355481723476/servers/450003", "rel": "self"}, {"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/38355481723476/servers/450003", "rel": "bookmark"}], "addresses": {"private": [{"version": 4, "addr": "10.7.116.240"}, {"version": 4, "addr": "15.185.169.230"}]}, "tenant_id": "38355481723XXX", "image": {"id": "44744", "links": [{"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/38355481723476/images/44744", "rel": "bookmark"}]}, "created": "2012-08-29T08:16:49Z", "uuid": "cf60fed2-6f22-4c88-b6fa-df006eb3aeac", "accessIPv4": "", "accessIPv6": "", "key_name": "service-instance", "progress": 100, "flavor": {"id": "104", "links": [{"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/38355481723476/flavors/104", "rel": "bookmark"}]}, "config_drive": "", "id": 450003, "security_groups": [{"name": "service-instance", "links": [{"href": "https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/38355481723476/os-security-groups/3268", "rel": "bookmark"}], "id": 3268}], "metadata": {}}}"

DEBUG [2012-08-29 07:04:50,678] jclouds.headers: >> GET https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/38355481723476/servers/450013 HTTP/1.1

DEBUG [2012-08-29 07:04:50,678] jclouds.headers: >> Accept: application/json

DEBUG [2012-08-29 07:04:50,678] jclouds.headers: >> X-Auth-Token: HPAuth_5034aee129c0e12c0726c35c

DEBUG [2012-08-29 07:04:50,796] jclouds.headers: << HTTP/1.1 401 Unauthorized

DEBUG [2012-08-29 07:04:50,796] jclouds.headers: << Date: Wed, 29 Aug 2012 08:23:35 GMT

DEBUG [2012-08-29 07:04:50,796] jclouds.headers: << Cneonction: close

DEBUG [2012-08-29 07:04:50,796] jclouds.headers: << Content-Type: text/plain; charset=UTF-8

DEBUG [2012-08-29 07:04:50,796] jclouds.headers: << Content-Length: 253

DEBUG [2012-08-29 07:04:50,796] jclouds.wire: << "401 Unauthorized[\n]"

DEBUG [2012-08-29 07:04:50,796] jclouds.wire: << "[\n]"

DEBUG [2012-08-29 07:04:50,796] jclouds.wire: << "This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.[\n]"

DEBUG [2012-08-29 07:04:50,796] jclouds.wire: << "[\n]"

DEBUG [2012-08-29 07:04:50,796] jclouds.wire: << "   "

DEBUG [2012-08-29 07:13:06,123] jclouds.headers: >> DELETE https://az-2.region-a.geo-1.compute.hpcloudsvc.com/v1.1/38355481723476/servers/450013 HTTP/1.1

DEBUG [2012-08-29 07:13:06,124] jclouds.headers: >> Accept: */*

DEBUG [2012-08-29 07:13:06,124] jclouds.headers: >> X-Auth-Token: HPAuth_5034aee129c0e12c0726c35c

DEBUG [2012-08-29 07:13:06,226] jclouds.headers: << HTTP/1.1 401 Unauthorized

DEBUG [2012-08-29 07:13:06,226] jclouds.headers: << Date: Wed, 29 Aug 2012 08:31:50 GMT

DEBUG [2012-08-29 07:13:06,226] jclouds.headers: << Cneonction: close

DEBUG [2012-08-29 07:13:06,227] jclouds.headers: << Content-Type: text/html; charset=UTF-8

DEBUG [2012-08-29 07:13:06,227] jclouds.headers: << Content-Length: 358

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << "<html>[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << " <head>[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << "  <title>401 Unauthorized</title>[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << " </head>[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << " <body>[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << "  <h1>401 Unauthorized</h1>[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << "  This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.<br /><br />[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << "[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << "[\n]"

DEBUG [2012-08-29 07:13:06,227] jclouds.wire: << "[\n]"

DEBUG [2012-08-29 07:13:06,228] jclouds.wire: << " </body>[\n]"

DEBUG [2012-08-29 07:13:06,228] jclouds.wire: << "</html>"

---

Let me know what you think. 

Thanks - Jonathan

[Jonathan]

Hi Everett,

It looks like the current RetryOnRenew implementation is expecting some specific response content that isn't there, at least not with all Keystone/Nova implementations, so the retry is never triggered. To answer the question posed by the TODO in that class:

//TODO: what is the error when the session token expires??

I'm not sure that we can reliably know when a 401 is because of an expired token as opposed to something else. Keystone may not even have a way of telling us that the provided token was expired. Perhaps it's best to just try obtaining a new token regardless.

Cheers,

Jonathan

On Friday, August 24, 2012 9:23:16 AM UTC-7, Everett Toews wrote:

[Adrian Cole]

The summary of this issue is that there's a miss in hp's implementation of the keystone api.  Instead of returning formatted json like other keystone impls do [1], it returns a vague html document, per your logs.

Can you ping HP to fix this?  The only other way would be to add a custom error handler that renews on all 401s.  I would certainly not advise doing so at the openstack-level; this code would need to go into the hp modules.

-A

[1] https://github.com/jclouds/jclouds/pull/307