Looking at the image you're using, it seems to be a deprecated one (isn't
it?).
You may want to filter out the deprecated images and avoid using them (I
recall having problems with disks when using some of them).
In the current impl, the deprecated field, when present, is populated in
the userMetadata map. You can safely filter out the images with the
deprecated key. That can be done by using the imageMatches method from
the TemplateBuilder with the appropriate predicate.
HTH!
El 12/11/2014 06:29, Sunil Shah su...@mesosphere.io escribió:
Sounds good - thanks again for the information!
On Tue, Nov 11, 2014 at 8:59 PM, Adrian Cole adrian.f.c...@gmail.com
wrote:
We haven't discussed timeframes for 1.9, yet, Sunil.
Danny, Ignasi and I have been working hard on GCE. Even if jclouds 1.9
release isn't complete, GCE will likely be stable by the end of November.
-A
On Nov 11, 2014 8:51 PM, Sunil Shah su...@mesosphere.io wrote:
Aha, thanks for the information Adrian! Do you have an approximate ETA
for 1.9?
Thanks,
Sunil
On Tue, Nov 11, 2014 at 8:48 PM, Adrian Cole adrian.f.c...@gmail.com
wrote:
2.0 snapshot has problems with firewall rules which prevent port 22
from being reached. This will be fixed before that code is promoted as
version 1.9.
-A
On Nov 11, 2014 8:42 PM, Sunil Shah su...@mesosphere.io wrote:
Hey User list,
We're seeing problems since upgrading to 2.0.0-SNAPSHOT from
1.8.2-SNAPSHOT. We're using jclouds-labs-google and when trying to
provision nodes, they block forever, despite the node now running:
2014-11-11 20:20:48,988 DEBUG [pool-3-thread-1] [] jclouds.compute
[SLF4JLogger.java:56] RUNNING node(us-central1-a/test-cluster-6-626)
2014-11-11 20:20:49,001 DEBUG [pool-3-thread-3] [] jclouds.compute
[SLF4JLogger.java:56] blocking on sockets [107.178.210.31:22,
10.27.249.104:22] for 60 MILLISECONDS
2014-11-11 20:20:52,044 DEBUG [pool-3-thread-2] [] jclouds.compute
[SLF4JLogger.java:56] RUNNING node(us-central1-a/test-cluster-6-bec)
2014-11-11 20:20:52,045 DEBUG [pool-3-thread-8] [] jclouds.compute
[SLF4JLogger.java:56] blocking on sockets [146.148.92.89:22,
10.31.244.213:22] for 60 MILLISECONDS
We haven't changed how we built the template:
builder.imageId(request.image)
.hardwareId(s${request.zone}/${request.machineType})
.locationId(request.zone)
.options(options.overrideLoginPrivateKey(Main.conf.privateKeyString))
.options(options.overrideLoginUser(request.sshUserName))
.options(options.authorizePublicKey(Main.conf.publicKeyString))
.build()
The serial output from the instance launched using 2.0.0-SNAPSHOT is
here, it looks like it can't find a boot disk:
https://gist.github.com/ssk2/7bfd47a1ee8965e51bdd
Serial output when the instance launches successfully using
1.8.2-SNAPSHOT is here:
https://gist.github.com/ssk2/19ae56c9f0d5f67cc5a5 using the same
image (backports-debian-7-wheezy-v20141108).
Any suggestions or ideas will be gratefully received :)
Sunil