Re: Nodes block forever on GCE
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
Jclouds openstack volume creation from image
Hi, In jclouds 1.8.0, I can see support for volume creation using snapshot Id but not using image id is it supported?
Blobstore Filesystem: does it work on shared folders with concurrent clients?
Does the filesystem blobstore provider work on shared folders, with concurrent clients? Does the provider handle locking and contention in naming? - Anthony
Re: Blobstore Filesystem: does it work on shared folders with concurrent clients?
Hi, Anthony. There is no synchronized, or mutex code in the current filesystem implementation. There are also no multithreaded tests to show it doesn't need that. In other words, I would use it only from a single thread, and synchronize externally. That said, you can always raise a pull request to help with the race conditions :) -A
Re: Virtualbox example?
Hi, Colin. VirtualBox has been dropped from jclouds labs as of version 1.9 [1]. We've stopped investing time in virtualization providers such as virtualbox or vsphere as they take inordinate amount of maintenance which displaces our ability to maintain cloud providers. I would look into other products, or the byon api, which allows you to use existing provisioned hosts in jclouds, or a cloud provider that works on local vms. https://github.com/jclouds/jclouds/tree/master/apis/byon -A [1] https://issues.apache.org/jira/browse/JCLOUDS-758
Re: Jclouds openstack volume creation from image
Hi Shital, I’m not sure what you’re trying to accomplish here. AFAIK, you can only create a volume from empty block storage or from a snapshot. I don’t think creating a volume from an image is possible. Exactly what OpenStack operation are you trying to do? Can you provide an example of doing it with the CLI or link us to some OpenStack doc that shows what you’re trying to do? Thanks, Everett On Nov 12, 2014, at 4:45 AM, Shital Patil shital.pa...@gslab.com wrote: Hi, In jclouds 1.8.0, I can see support for volume creation using snapshot Id but not using image id is it supported?
Re: Question about JCLOUDS-658 Jira issue
Hi Adrian/Andrew, thank you very much for your replies. This information will be really helpful to continue my evaluation of jclouds. Cheers, Gabriel 2014-11-12 0:34 GMT-08:00 Andrew Gaul g...@apache.org: On Mon, Nov 10, 2014 at 05:45:10PM -0800, Gabriel Lavoie wrote: I'm currently reviewing the jclouds filesystem blobstore API. I noticed that user metadata doesn't get saved with the 1.8.1 version, but that a comment exists in the code regarding Java 7 and NIO filestore attributes. I also found out with the JCLOUDS-658 that jclouds 2.0 (unreleased) fixes the issue by using the NIO filestore attributes. Regarding this issue and resolution: - Is the filesystem API considered production safe or only suggested for testing/debugging? - I'm not sure about the solution of using the filesystem metadata store to store metadata. Many (most?) filesystem archival/backup/explorer are not aware of this metadata and it may get lost without the user knowing about it. I would consider using this for testing, but never in a production environment. - Could an alternate way of storing metadata be implemented, for example in a properties file named id.metadata stored alongside with the object file? - I could implement a file metadata storage by wrapping FilesystemStorageStrategyImpl, but I don't think this is a good idea to wrap it as I have to re-implement a few classes to have the dependency injection work correctly. The filesystem blobstore has traditionally been used for testing purposes and has a few caveats for production use. However, it should perform well enough for applications with a small number of objects (tens of thousands) and small object sizes (gigabytes). My primary concern for production use is that a filesystem is not a blobstore; a single node lacks the performance and reliability that a multi-node Swift installation provides. While Swift uses a filesystem to stores its blob data, it uses XFS with several tuning parameters and hashes object names into directory shards to avoid scalability limits. The filesystem blobstore has a few known issues; we will gladly accept patches for these: * scalability: returning a paginated list of objects creates the entire list in-memory * compatibility: lacks multi-part upload, some listing options not supported * error paths: writing partial objects or concurrently overwriting objects has different semantics than real object stores, especially on Windows * performance: excessive system calls on various code paths * metadata: 1.8.1 does not support user metadata and other attributes. The approach for future releases only works on Linux and Windows. Current JDK on Mac OS X does not support xattr (JDK-8030048). Using file extended attributes is the right way to store object metadata and allows other tools to interact with these objects instead of using a special format that only jclouds understands. However, I appreciate the practical reasons to prefer another approach; could you explore this issue further? Every solution has a trade-offs, for example storing in id.metadata file requires extra work when listing objects. You may want to consider using a second directory for metadata instead. Finally you might want to look at Jimfs which creates an in-memory filesystem provider; perhaps you could create an on-disk provider which stores extended attributes in some other way? -- Andrew Gaul http://gaul.org/ -- Gabriel Lavoie glav...@gmail.com
RE: Neutron API versions v2 and v2_0
v2_0 is deprecated. If you are just starting with Neutron, use v2. Thanks! -Zack From: Raj [r...@apache.org] Sent: Wednesday, November 12, 2014 10:54 AM To: user@jclouds.apache.org Subject: Neutron API versions v2 and v2_0 Hi, Why there two versions(v2 and v2_0) in 1.8.1 release of neutron API [1] Could you please let me know the difference between these two and which one to use in a production environment? 1. https://github.com/jclouds/jclouds-labs-openstack/tree/jclouds-labs-openstack-1.8.1/openstack-neutron/src/main/java/org/jclouds/openstack/neutron Regards. -- Rajkumar Rajaratnam Committer PMC Member, Apache Stratos Software Engineer, WSO2
