Hi Daniel, This was reported recently (see JCLOUDS-528 [1]) and fixed in master. If you use the latest 1.8.0-SNAPSHOT version you should be able to set the ""jclouds.compute.socket-finder-allowed-interfaces" property to control which IP addresses are used to connect to the node (see [2]).
We are about to release 1.7.3, and if no one says the opposite I'll back port that fix in a while, so if that works for you, you should be able to use it in the next release. HTH! [1] https://issues.apache.org/jira/browse/JCLOUDS-528 [2] https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/config/ComputeServiceProperties.java#L111-L114 On 25 May 2014 18:59, Daniel Widdis <[email protected]> wrote: > I am using jclouds to provision and configure servers on a Rackspace Hybrid > Cloud. Specifically, I have a dedicated/managed server, which I connect to > via VPN, and regularly need to start up additional cloud servers to offload > some processing work. The sequence of events on the server side is: > > 1. Server is created with a public IP and private IP > 2. Server starts up and becomes accessible via ssh > 3. Immediately after becoming accessible, a script executes on the Rackspace > side to disable the public IP > 4. The script proceeds to connect to the server as root and configure it > with a "RackConnect" IP address. This is still a publicly reachable address > but is different than the original Public IP. > > My code is similar to the example at > https://github.com/jclouds/jclouds-examples/blob/master/rackspace/src/main/java/org/jclouds/examples/rackspace/cloudservers/CloudServersPublish.java > with the exception that I am using the privateIP for the awaitSsh() call. > However, the RunScriptOnNode() call uses the NodeMetadata as an argument, > and apparently attempts to connect to both public and private IP addresses. > Most of the time, my connection occurs in between steps 3 and 4 above, > before the RackConnect IP is provisioned, and I experience no problems. But > about 2-3% of the time, RunScriptOnNode attempts to use the RackConnect IP. > > Because of the way Rackspace operates their firewall, if public connections > to my hybrid cloud are turned off, then connections on the RackConnect IP > time out, rather than being refused. This gives me the unfortunate result > of failed connections. What is frustrating is that although the code > attempts to reconnect multiple times, it continues to try the (timing out) > RackConnect IP rather than attempting any other IP (such as the private IP, > which is accessible.) > > A similar issue was discussed on this thread: > https://groups.google.com/forum/#!topic/jclouds/TBpDtt9jaTo In that case, > the user wanted the public IP rather than the private, but the inability to > choose between them is noted. At the end of that thread, it was implied > that an issue was filed in github. However, the project has since moved to > Apache and I have not been able to find anything related to this issue in > the current JIRA tracking system. > > Of note, the RackConnect IP is placed in the " accessIPv4" field, and added > to the list of public addresses from there (see > https://issues.apache.org/jira/browse/JCLOUDS-355 ) I don't know if this is > relevant. > > Ultimately, this boils down to a possible bug, and a feature request: > > 1. It may be a bug that the RunScriptOnNode() method does not attempt any > other IPs after expeirencing a failed/timed-out connection on one of them. > > 2. It would be a nice-to-have feature to modify the RunScriptOnNode method > to allow a user to specify either public (to deconflict with another private > network) or private (to avoid bandwidth charges and allow firewalled > security measures) IP addresses, as discussed in the mailing list thread > cited above. > > Dan
