docker location's default password leaks into other location

[aledsage]

With persistence enabled (--persist auto) I restarted brooklyn. There were existing locations for jclouds-docker and jclouds-cloudstack.

I then attempted to deploy an app to a cloudstack 4.3 environment. It failed with the jclouds exception below.

Note this password hash corresponds to "password".

When I ran without --persist auto it worked fine.

This is with docker-1.7.2-ea-brooklyn.5.jar; see https://github.com/andreaturli/jclouds-labs/tree/1.7.2-ea-brooklyn.5

---

1. AuthorizationException on node 8a45cec6-1638-40d9-a939-33de61d90136:
   org.jclouds.rest.AuthorizationException: (root:pw[5f4dcc3b5aa765d61d8327deb882cf99]@10.47.2.216:22) (root:pw[5f4dcc3b5aa765d61d8327deb882cf99]@10.47.2.216:22) error acquiring {hostAndPort=10.47.2.216:22, loginUser=root, ssh=null, connectTimeout=60000, sessionTimeout=6
   0000} (out of retries - max 50): Exhausted available authentication methods
   at org.jclouds.sshj.SshjSshClient.propagate(SshjSshClient.java:380)
   at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:201)
   at org.jclouds.sshj.SshjSshClient.connect(SshjSshClient.java:221)
   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:1156)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
   at java.lang.Thread.run(Thread.java:804)
   Caused by: net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods
   at net.schmizz.sshj.userauth.UserAuthImpl.authenticate(UserAuthImpl.java:114)
   at net.schmizz.sshj.SSHClient.auth(SSHClient.java:205)
   at net.schmizz.sshj.SSHClient.auth(SSHClient.java:190)
   at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:266)
   at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:236)
   at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:220)
   at org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:138)
   at org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:38)
   at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:191)
   ... 10 more
   Caused by: net.schmizz.sshj.userauth.UserAuthException: keyboard-interactive auth failed
   at net.schmizz.sshj.userauth.UserAuthImpl.handle(UserAuthImpl.java:157)
   at net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:474)
   at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:127)
   at net.schmizz.sshj.transport.Decoder.received(Decoder.java:195)
   at net.schmizz.sshj.transport.Reader.run(Reader.java:72)

[aledsage]

It works when I comment out this line from org.jclouds.docker.DockerApiMetadata.defaultProperties()

`properties.setProperty(ComputeServiceProperties.IMAGE_LOGIN_USER, "root:password");`

This method is called as a result of the persisted locations, because we create a ComputeService for the docker provider when rebinding to the docker location. (When persistence is disabled, this code does not get called).

I have three hypotheses why this could make it fail:

1. this property set in the docker ComputeService somehow leaks into the cloud stack ComputeService, e.g. through statics or a shared instance injected through juice!? This would be very surprising because jclouds is extremely careful and separation.
2. within brooklyn, the value is read and ends up in a brooklyn docker location. Some state leaks from this location into our cloud stack location. I've no idea how that would happen though (I ran a test that disabled the sharing of ComputeService in JcloudsUtil.findComputeService() and it still failed).
3. the ComputeServiceProperties.IMAGE_LOGIN_USER somehow interferes with our JcloudsLocation.LOGIN_USER_PASSWORD

Of these, (1) seems most likely to me currently.

My next step is to rebind to the state, then start a VM in an AWS location (so I can run it outside of the locked-down customer environment), and see if that uses "password". If it does, then I'll breakpoint and see where that is coming from.