On Wed, Dec 18, 2013 at 07:59:48PM +0100, Andrew Phillips wrote: > With #239 [1], we'll hopefully be able to get an interesting and useful > benchmarking tool from Maginatics out to the wider jclouds audience. Some > debate going on in the issue, though, about where the right place for this > and related administrative tools and utilities should be. > > I personally would like to keep these out of jclouds itself, since I see > things in there more as libraries than standalone tools or distributions (we > haven't used the "distribution" profile [2] for ages now, and I think it > should probably be removed). > > Curious to hear what others think..?
To gives some scope, Maginatics hopes to release a series of tools under the jclouds umbrella: BlobStoreBench will be the first tool, which gathers bandwidth and latency statistics. This allows exploring different naming schemes for blobs, e.g., AWS-S3 prefers naming blobs with a random prefix, Atmos prefers a limited number of blobs per directory, and Swift prefers distributing blobs between containers. BlobStoreValidator diagnoses blobstore compatibility, usually used with S3- or Swift-compatible private blobstores which have varying authentication, service paths, and quirks like MD5 support. BlobStoreCli replaces some uses of the existing karaf-based jclouds-cli using really-executable-jar. This offers a more intuitive user experience and slimmer binary size. Returning to your question, I prefer to put these in the main repository since they impose little testing and packaging overhead. Further the explosion of repositories makes developing and releasing jclouds painful as we encounter regressions and inconsistencies when making changes to a single repository. We should endeavor to bring more code into the main repository, e.g., jclouds-chef. Finally hosting these in the main repository makes these tools more discoverable by our users. -- Andrew Gaul http://gaul.org/
