jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Phillips <aphill...@qrmedia.com>
Subject Re: jclouds-cli problems
Date Mon, 06 Apr 2015 21:49:06 GMT
> That should minimize the impact of the issue, and allow normal
> operation when jclouds knows how to conenct to the node.
>
> WDYT?

If I understand your proposal correctly, you mean essentially moving  
the first attempt to find a connector to here:

https://github.com/jclouds/jclouds/blob/master/drivers/sshj/src/main/java/org/jclouds/sshj/SSHClientConnection.java#L166

? That would certainly help in the sense that, if you're providing any  
one of the other connection methods, you would not see this problem.

I'm not sure what would happen in case you *do* want to use an  
agentproxy, though. I guess what we want to ensure is that, if  
usocket-nc works on your system, you do *not* get an error when using  
jclouds-cli.

I think we would need to verify this...and then we should probably  
also document (if not already done) that agent proxying is *only*  
supported using netcat, i.e. not on Windows or using JNA.

If I put together a quick PR that moves the first call to JSch's  
ConnectorFactory as you describe, would you be able to test whether a  
CLI built using that patch works with netcat available?

Regards

ap

Mime
View raw message