Thanks, Can you isolate the failure in a small program we could use to reproduce it?
What might be relevant is the use of the TemplateBuilder and TemplateOptions. There are several options (such as authorizePublicKey or installPrivateKey) that translate into statements that are executed via SSH. I don't remember exactly if the authorizePublicKey one causes an SSH connection in GCE (providers that support key pairs implement it using the API and not an SSH script) but I'll have a look. Meanwhile, could you share which template options are you using? I. El 07/07/2014 04:15, "Jason Dusek" <[email protected]> escribió: > Hi Ignasi, > > Thanks for being willing to help out. > > Because the code base is proprietary, and factored into a few > components that are generic in their handling of the different clouds, > it's quite difficult to extract a snippet that brings together all the > ingredients in an illustrative way. > > Is there some logging I could add or some options I could set for > better diagnostics? > > It would be great if you could explain what triggers > RunScriptOnNodeAsInitScriptUsingSsh, because if we can find a way to > delay or disable it, it'd put an end to our troubles. If we're careful > to catch the exception caused by this component and then to scan over > available instances to find the relevant ones, generally we find that > everything came up okay and we're able to move forward with the > deployment -- so there appears to be no harm in skipping the > RunScriptOnNodeAsInitScriptUsingSsh task. > -- > Jason Dusek > @solidsnack > > > On 5 July 2014 07:23, Ignasi Barrera <[email protected]> wrote: > > Hi Jason, > > > > Could you share the code snippet you use to create the nodes, so we can > try > > to reproduce it? > > > > Thanks! > > > > I. > > > > El 03/07/2014 23:46, "Daniel Widdis" <[email protected]> escribió: > > > >> I can't answer specific to GCE, but with Rackspace I've used an > awaitSsh() > >> call first, which just sits and waits for the SSH to be available (or > times > >> out after a long time). Once that method returns, you can use other > methods > >> to log in and run scripts. It sounds like a similar thing would work > for > >> you. > >> > >> Here's the awaitSsh() stolen from the examples on the jclouds site: > >> > >> /** > >> * Wait until ssh is available on specified ip > >> * > >> * @param ip > >> * The IP Address to check > >> * @throws TimeoutException > >> */ > >> private void awaitSsh(String ip) throws TimeoutException { > >> // SshjSshClientModule module = new SshjSshClientModule(); > >> SocketOpen socketOpen = > computeService.getContext().utils().injector() > >> .getInstance(SocketOpen.class); > >> Predicate<HostAndPort> socketTester = retry(socketOpen, 300, 5, 5, > >> SECONDS); > >> socketTester.apply(HostAndPort.fromParts(ip, 22)); > >> } > >> > >> > >> On 7/3/14, 2:01 PM, Jason Dusek wrote: > >>> > >>> Hi All, > >>> > >>> When provisioning instances on Google's Compute Engine service, > >>> we are encountering a failure when jClouds attempts to SSH in to > >>> the instance early in the boot process. > >>> > >>> The exception is thrown as a result of a call to > >>> `computeService.createNodesInGroup()`. When the error is thrown, > >>> the SSH user and key which are being used are printed in the > >>> stack trace. Logging in using the SSH CLI tool, passing the > >>> indicated user and key, works as expected. > >>> > >>> One question that arises from all this is: why is jClouds > >>> logging into the servers this early? Is there something in the > >>> template that causes it to try to configure something? The > >>> options passed to the template are in this case very simple; in > >>> particular, no `runScript()` options are passed. > >>> > >>> Another is: what is a safe and reasonable way to resolve this > >>> error case? Perhaps there is a way to delay the step where > >>> jClouds SSHes to the instance, or to disable the > >>> `RunScriptOnNodeAsInitScriptUsingSsh` step entirely. > >>> > >>> We've found jClouds to be a big help so far and it'd be great to > >>> find an idiomatic way to resolve this issue. Please let me know > >>> if there is any additional information I can provide. > >>> > >>> -- > >>> Jason Dusek > >>> @solidsnack > >>> > >>> > >>> > >>> > >>> [2014-07-03 17:17:47,000] ERROR << problem customizing > >>> node(us-central1-a/silly-cluster-cd758a1c-fc8): (jclouds.compute:91) > >>> org.jclouds.rest.AuthorizationException: > >>> > >>> > (jclouds:rsa[fingerprint(88:06:0b:b5:67:34:d2:ef:71:10:b8:e5:8d:e9:ea:65),sha1(c4:07:6b:1f:cf:f1:32:51:96:70:eb:43:77:ee:74:84:8c:da:bf:6d)]@ > 173.255.113.102:22) > >>> > >>> > (jclouds:rsa[fingerprint(88:06:0b:b5:67:34:d2:ef:71:10:b8:e5:8d:e9:ea:65),sha1(c4:07:6b:1f:cf:f1:32:51:96:70:eb:43:77:ee:74:84:8c:da:bf:6d)]@ > 173.255.113.102:22) > >>> error acquiring {hostAndPort=173.255.113.102:22, loginUser=jclouds, > >>> connectTimeout=60000, sessionTimeout=60000}: Auth fail > >>> at > >>> org.jclouds.ssh.jsch.JschSshClient.propagate(JschSshClient.java:335) > >>> at > >>> org.jclouds.ssh.jsch.JschSshClient.acquire(JschSshClient.java:187) > >>> at > >>> org.jclouds.ssh.jsch.JschSshClient.connect(JschSshClient.java:200) > >>> at > >>> > org.jclouds.compute.callables.RunScriptOnNodeAsInitScriptUsingSsh.call(RunScriptOnNodeAsInitScriptUsingSsh.java:76) > >>> at > >>> > org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:125) > >>> at > >>> > org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.apply(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:146) > >>> at > >>> > org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.apply(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:53) > >>> at > >>> com.google.common.util.concurrent.Futures$1.apply(Futures.java:711) > >>> at > >>> > com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:849) > >>> at > >>> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >>> at > >>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >>> at java.lang.Thread.run(Thread.java:724) > >>> Caused by: com.jcraft.jsch.JSchException: Auth fail > >>> at com.jcraft.jsch.Session.connect(Session.java:491) > >>> at > >>> > org.jclouds.ssh.jsch.SessionConnection.create(SessionConnection.java:186) > >>> at > >>> > org.jclouds.ssh.jsch.SessionConnection.create(SessionConnection.java:39) > >>> at > >>> org.jclouds.ssh.jsch.JschSshClient.acquire(JschSshClient.java:180) > >>> ... 10 more > >> > >> > > >
