incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamshid Afshar" <jamshid.afs...@caringo.com>
Subject Re: Review Request: Add initial support for Caringo's CAStor object storage as the S3 backend.
Date Fri, 10 Aug 2012 23:46:43 GMT


> On Aug. 10, 2012, 10:52 p.m., Ewan Mellor wrote:
> > Jamshid, what is the license on CAStorSDK.jar and jmdns-2.1.jar?  I presume CAStorSDK
is one that you own -- what about the other one?  The license on dependent libraries affects
whether we can build the code as part of the default build or not.  If it is an open-source
license that is compatible with the Apache license then things are very easy, but otherwise
things get more complicated.
> > 
> > As general guidance:
> > 
> > The easiest thing to do is to license your code under the Apache license, or a compatible
one such as BSD.  This will mean that we can have the default CloudStack build include support
for your object store, which is obviously a big win.
> > 
> > The Apache Foundation won't allow code that requires proprietary libraries in the
default configuration, so if you can't do this, then the feature would have to be off by default.
 This isn't the end of the world, but it means that users would have to recompile CloudStack
from source to enable your software.  This would be the case if that jar is only available
to CAStor customers or otherwise not freely distributable.  We're going to have to turn off
NetApp support in the default build for this reason, to give you an example.
> > 
> > 
> > I don't know if you know this, but we're trying to get a CloudStack 4.0 release
together in the next month.  The deadline for feature freeze is today, with the deadline for
sorting out all licensing issues being next week.  For your patch to get in, we'd have to
get these license issues resolved very soon, and make an exception to the feature freeze.
 If there is going to be any delay figuring out the licensing on these jars, would it be a
problem if this patch didn't get into CloudStack 4.0?  If that's OK, it would go immediately
on the list for 4.1 instead.  That would give you time to sort out what you want to do here.
> > 
> > Please let me know what you're planning to do at this point, so that we can finalize
the upcoming release.
> >
> 
> Eric Dey wrote:
>     Ewan, I'll answer for Jam in his absence. The JmDNS package is an Apache 2.0 license
while the Caringo CAStorSDK package is a BSD license.
> 
> Ewan Mellor wrote:
>     OK, that's great, thanks.  Please give download URLs for those.  We want our build
system to be able to download them from the official upstream servers, and we want to document
where to get them if users need to upgrade.  Thanks.
>

Sure, Ewan, we really want this feature in the CloudStack 4.0 release.

Here is the jmdns library's license: http://jmdns.sourceforge.net/license.html

I'll attach the license for our SDK jar and find out about a download url.

Btw Edison, the 2 binary files are in the attached patch file, not sure why the ui doen't
let you download them individually.


- Jamshid


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6473/#review10157
-----------------------------------------------------------


On Aug. 9, 2012, 2:24 a.m., Jamshid Afshar wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6473/
> -----------------------------------------------------------
> 
> (Updated Aug. 9, 2012, 2:24 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> -------
> 
> Below is the commit message. This is my first patch, let me know if I did anything wrong
or if e.g. using "storage.root" is not how configuring a new storage backend should be done.
> 
> Add initial support for Caringo's CAStor object storage as the S3 backend.
> 
> Similar to the s3-hdfs example. Now storage.root can specify "castor"
> followed by a list of IP addresses for the nodes in the CAStor
> cluster. S3 operations will then create and read buckets and objects
> in CAStor instead of a file system.
> 
> 
> Diffs
> -----
> 
>   awsapi/src/com/cloud/bridge/io/S3CAStorBucketAdapter.java PRE-CREATION 
>   awsapi/src/com/cloud/bridge/model/SHost.java 874b095 
>   awsapi/src/com/cloud/bridge/service/controller/s3/ServiceProvider.java 7a36a4b 
>   awsapi/src/com/cloud/bridge/service/core/s3/S3Engine.java e8b73a4 
>   deps/awsapi-lib/CAStorSDK.jar PRE-CREATION 
>   deps/awsapi-lib/jmdns-2.1.jar PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/6473/diff/
> 
> 
> Testing
> -------
> 
> Tested a boto script I believe we got from Chiradeep (localhost_test.py) that creates
buckets and streams, does a range read and delete. I will continue to do more testing (http://wiki.cloudstack.org/display/QA/How+to+run+S3+Tests+against+CloudStack+S3+Implementation).
> 
> 
> Thanks,
> 
> Jamshid Afshar
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message