----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6473/#review10157 -----------------------------------------------------------
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. - Ewan Mellor 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 > >
