Notes from a jclouds user chat with Mesosphere

[Andrew Phillips <ap...@qrmedia.com>]

Here the notes from a very informative call I had with Michael Jin  
from Mesosphere, who kindly took the time to share feedback and  
suggestions about how to improve (working with) jclouds.

Longer notes are below, but the TL;DR for me was:

1. Easier ability to hook in custom failure handling that a) can  
access the underlying error to perform provider-specific recovery b)  
can also be triggered if e.g. a node is "dud"  (for some user-defined  
definition of "dud") even if the API isn't erroring out
2. The time between submitting a PR and having that available in a  
stable version (i.e. not a snapshot) needs to be much shorter. It's  
not clear which part is most in need of improvement - the time to get  
a PR merged, or the time for it to appear in a stable release - but  
from a user's perspective it's the end-to-end time that matters
3. We should be trying to give as much Guava flexibility as possible:  
users should not be stuck on an old branch to use older Guava  
versions, and should be able to use new branches with versions of  
Guava newer than on the branch

@Michael: thanks for this, and please correct/amend where necessary!

@all: if you're aware of other jclouds end users who'd be interested  
in similarly sharing their thoughts, please let me know!

Regards

ap

Full notes:

* working on GCE and DigitalOcean (dropped AWS for now)
* need to support potential users who can't try different clouds
* cloud-abstraction library minimizes the amount of code we need
* not too many provider-specific calls but finding differences (e.g. auth)
* lots of "build template" and "runNodesInGroup"

Specific points:
* exception handling (barfs from the provider) - need to have more  
ability to be explicit about retry handling and there isn't much  
visibility into the actual exception
* #1 pain point
* being able to override retry handling at the context level?
* ...or at the call level?
* What if the provider is "lying" to me (i.e. no Exception being  
thrown) - can I have retry logic for "semantic" problems?

* would be nice if provider coverage would be quicker
* taking longer than expected to merge back upstream
* ideally, should be a) included in the code and b) available in a  
stable release "reasonably soon"
* working off master (possibly related to Guava)
* need to verify whether it's possible to use 1.8.x and override the  
Guava version if needed