Re: [jclouds/jclouds-karaf] Try to use an OSGi-compliant way of loading JSR 223 script engines (#79)
+1! Many thanks @demobox! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/79#issuecomment-246259756
Re: [jclouds/jclouds-karaf] Use same bundle version as in jclouds/project/java-xmlbuilder.verison (#81)
Merged #81. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/81#event-785928303
Re: [jclouds/jclouds-karaf] Use same bundle version as in jclouds/project/java-xmlbuilder.verison (#81)
@demobox lgtm too -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/81#issuecomment-246342026
Re: [jclouds/jclouds-karaf] Use same bundle version as in jclouds/project/java-xmlbuilder.verison (#81)
Thanks, @neykov! Pending the CI build, looks good to me. For reference for anyone who's interested, this is the bundle, I think: http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22org.apache.servicemix.bundles.java-xmlbuilder%22 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/81#issuecomment-246341864
Re: [jclouds/jclouds-karaf] Use same bundle version as in jclouds/project/java-xmlbuilder.verison (#81)
thanks @neykov -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/81#issuecomment-246346027
[jclouds/jclouds-karaf] Use same bundle version as in jclouds/project/java-xmlbuilder.verison (#81)
https://github.com/jclouds/jclouds/blob/master/project/pom.xml#L235 You can view, comment on, or merge this pull request online at: https://github.com/jclouds/jclouds-karaf/pull/81 -- Commit Summary -- * Use same bundle version as in jclouds/project/java-xmlbuilder.verison -- File Changes -- M pom.xml (2) -- Patch Links -- https://github.com/jclouds/jclouds-karaf/pull/81.patch https://github.com/jclouds/jclouds-karaf/pull/81.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/81
Re: [jclouds/jclouds] Some handles were not properly closed (#1007)
> @@ -701,14 +702,11 @@ public void downloadBlob(String container, String name,
> File destination, Execut
> Futures.getUnchecked(Futures.allAsList(results));
>
>} catch (IOException e) {
> - // cleanup, attempt to delete large file
> - if (raf != null) {
> -try {
> - raf.close();
> -} catch (IOException e1) {}
> - }
> + Closeables2.closeQuietly(raf);
You can do what @nacx suggests with slightly more complicated resource
management:
```java
RandomAccessFile raf = null;
File tmpFile = null;
try {
tempFile = new File(...);
raf = new RandomAccessFile(tempFile);
raf.write(...);
raf.close();
raf = null;
tempFile.renameTo(destinationFile);
tempFile = null;
} finally {
Closeables2.closeQuietly(raf);
if (tempFile != null) {
tempFile.delete();
}
}
```
This ensures that `destinationFile` is not overwritten unless the download
succeeds.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1007/files/0003721c3e983e3f3c08824d86cbc7e5098f4eb4#r78420532
[jira] [Created] (JCLOUDS-1177) Azure object encryption
Andrew Gaul created JCLOUDS-1177: Summary: Azure object encryption Key: JCLOUDS-1177 URL: https://issues.apache.org/jira/browse/JCLOUDS-1177 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.9.2 Reporter: Andrew Gaul Assignee: Rita Zhang Microsoft announced GA availability of object encryption: https://blogs.msdn.microsoft.com/windowsazurestorage/2016/09/12/announcing-the-general-availability-of-storage-service-encryption-for-data-at-rest/ jclouds should support this. [~ritazh] Could you look into this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jclouds/jclouds] JCLOUDS-532: Properly close HTTP streams (#700)
@nacx This seems to breaking swift delete operation. Swift Delete operation used to be Idempotent but after this change second delete operation is failing with these stack traces `org.jclouds.http.HttpResponseException: java.io.IOException: stream is closed connecting to DELETE https://dal05.objectstorage.softlayer.net/v1/AUTH_0eb7ef10-6761-4384-ab47-9187592f30b1/cloud-testing/74f346838a7b550f HTTP/1.1 at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:114) at org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90) at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73) at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44) at org.jclouds.rest.internal.DelegatesToInvocationFunction.handle(DelegatesToInvocationFunction.java:156) at org.jclouds.rest.internal.DelegatesToInvocationFunction.invoke(DelegatesToInvocationFunction.java:123) at com.sun.proxy.$Proxy67.removeObject(Unknown Source) at org.jclouds.openstack.swift.blobstore.SwiftBlobStore.removeBlob(SwiftBlobStore.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:37) at com.sun.proxy.$Proxy69.removeBlob(Unknown Source) at com.maginatics.raptor.data.BlobStoreTest.testBlobRemoveIdempotence(BlobStoreTest.java:208) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393) at org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54) at org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.RuntimeException: java.io.IOException: stream is closed at com.google.common.base.Throwables.propagate(Throwables.java:160) at org.jclouds.http.HttpUtils.toByteArrayOrNull(HttpUtils.java:127) at org.jclouds.http.HttpUtils.closeClientButKeepContentStream(HttpUtils.java:159) at org.jclouds.openstack.swift.handlers.ParseSwiftErrorFromHttpResponse.handleError(ParseSwiftErrorFromHttpResponse.java:49) at org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:65) at
[jira] [Updated] (JCLOUDS-1177) Azure object encryption
[ https://issues.apache.org/jira/browse/JCLOUDS-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Gaul updated JCLOUDS-1177: - Description: Microsoft announced general availability of object encryption: https://blogs.msdn.microsoft.com/windowsazurestorage/2016/09/12/announcing-the-general-availability-of-storage-service-encryption-for-data-at-rest/ jclouds should support this. [~ritazh] Could you look into this? was: Microsoft announced GA availability of object encryption: https://blogs.msdn.microsoft.com/windowsazurestorage/2016/09/12/announcing-the-general-availability-of-storage-service-encryption-for-data-at-rest/ jclouds should support this. [~ritazh] Could you look into this? > Azure object encryption > --- > > Key: JCLOUDS-1177 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1177 > Project: jclouds > Issue Type: New Feature > Components: jclouds-blobstore >Affects Versions: 1.9.2 >Reporter: Andrew Gaul >Assignee: Rita Zhang > Labels: azureblob > > Microsoft announced general availability of object encryption: > https://blogs.msdn.microsoft.com/windowsazurestorage/2016/09/12/announcing-the-general-availability-of-storage-service-encryption-for-data-at-rest/ > jclouds should support this. [~ritazh] Could you look into this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jclouds/jclouds] Add keystone authentication with an existing token (#1009)
This pull request adds the possibility to use JClouds for OpenStack with a
pre-existing Keystone token.
Cf.
http://developer.openstack.org/api-ref/identity/v2/?expanded=authenticate-detail
To authenticate with a tenant name and a token, you can do:
```
Properties config = new Properties();
config.setProperty(KeystoneProperties.CREDENTIAL_TYPE,
CredentialTypes.TOKEN_CREDENTIALS);
ContextBuilder.newBuilder("openstack-neutron")
.overrides(config)
.credentials("tenantname:", "hereisthetoken")
...
```
To authenticate with a tenant ID and a token, you can do:
```
Properties config = new Properties();
config.setProperty(KeystoneProperties.CREDENTIAL_TYPE,
CredentialTypes.TOKEN_CREDENTIALS);
config.setProperty(KeystoneProperties.TENANT_ID, "tenantid");
ContextBuilder.newBuilder("openstack-neutron")
.overrides(config)
.credentials("", "hereisthetoken")
...
```
NB1: auto-value is added to the project `openstack-keystone` because this is
JCloud's good practice
(https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=49578594#API/ProviderWritingPractices-(Start)UsingAuto-Valueforallvaluetypes)
NB2: `@CredentialType` is made `@Inherited` because the AutoValue concrete
class must have the annotation.
You can view, comment on, or merge this pull request online at:
https://github.com/jclouds/jclouds/pull/1009
-- Commit Summary --
* Add keystone authentication with an existing token
-- File Changes --
M apis/openstack-keystone/pom.xml (5)
M
apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/AuthenticationApi.java
(26)
M
apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/config/CredentialType.java
(2)
M
apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/config/CredentialTypes.java
(2)
M
apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/config/KeystoneAuthenticationModule.java
(2)
M
apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/config/KeystoneProperties.java
(1)
A
apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/domain/TokenCredentials.java
(53)
A
apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/functions/AuthenticateTokenCredentials.java
(59)
M
apis/openstack-keystone/src/main/java/org/jclouds/openstack/keystone/v2_0/functions/internal/BaseAuthenticator.java
(8)
-- Patch Links --
https://github.com/jclouds/jclouds/pull/1009.patch
https://github.com/jclouds/jclouds/pull/1009.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1009
Re: [jclouds/jclouds] JCLOUDS-1161: Make AWSS3BlobRequestSignerV4 the default signer. (#1008)
Added a new live test, specifically run against eu-central-1 region. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1008#issuecomment-246511656
Re: [jclouds/jclouds] Add keystone authentication with an existing token (#1009)
Not a bad idea to have that as an option! However, I have to point out that jclouds retry mechanisms will not be able to re-authenticate and get a new token once the token expires, so this type of authentication might not work in some user environments. I think it's still worth it to have it. Are there any additional tests that need to be added to this? (see https://github.com/jclouds/jclouds/blob/master/apis/openstack-keystone/src/test/java/org/jclouds/openstack/keystone/v2_0/internal/BaseKeystoneRestApiExpectTest.java) Also, always good to see more AutoValue refactoring. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1009#issuecomment-246529141
Re: [jclouds/jclouds] Some handles were not properly closed (#1007)
> @@ -701,14 +702,11 @@ public void downloadBlob(String container, String name,
> File destination, Execut
> Futures.getUnchecked(Futures.allAsList(results));
>
>} catch (IOException e) {
> - // cleanup, attempt to delete large file
> - if (raf != null) {
> -try {
> - raf.close();
> -} catch (IOException e1) {}
> - }
> + Closeables2.closeQuietly(raf);
Good point, I'll submit a quick PR for it and one other small fix.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1007/files/0003721c3e983e3f3c08824d86cbc7e5098f4eb4#r78471081
Re: [jclouds/jclouds] JCLOUDS-1161: Make AWSS3BlobRequestSignerV4 the default signer. (#1008)
Tests show the following errors:
```
$ mvn integration-test -pl :aws-s3 -Plive
-Dtest.aws-s3.identity="${JCLOUDS_IDENTITY}"
-Dtest.aws-s3.credential="${JCLOUDS_CREDENTIAL}" -Dtest=AWSS3BlobSignerLiveTest
...
Failed tests:
AWSS3BlobSignerLiveTest>S3BlobSignerLiveTest.testSignGetUrlWithTime:39->BaseBlobSignerLiveTest.testSignGetUrlWithTime:92->BaseBlobStoreIntegrationTest.assertConsistencyAwareContainerSize:311->BaseBlobStoreIntegrationTest.assertConsistencyAware:252->BaseBlobStoreIntegrationTest.assertConsistencyAware:239
» ContainerNotFound
AWSS3BlobSignerLiveTest>S3BlobSignerLiveTest.testSignPutUrlWithTime:60 null
AWSS3BlobSignerLiveTest>S3BlobSignerLiveTest.testSignGetUrlWithTimeExpired:49->BaseBlobSignerLiveTest.testSignGetUrlWithTimeExpired:115
» AWSResponse
AWSS3BlobSignerLiveTest>S3BlobSignerLiveTest.testSignPutUrlWithTimeExpired:69->BaseBlobSignerLiveTest.testSignPutUrlWithTimeExpired:179
» AWSResponse
Tests run: 8, Failures: 4, Errors: 0, Skipped: 0
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1008#issuecomment-246572568
[jira] [Commented] (JCLOUDS-1174) Transient and Azure blob do not filter out marker blobs from blob exists
[
https://issues.apache.org/jira/browse/JCLOUDS-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486306#comment-15486306
]
Andrew Gaul commented on JCLOUDS-1174:
--
[~ritazh] [~jasonpoon] Could you investigate this?
> Transient and Azure blob do not filter out marker blobs from blob exists
>
>
> Key: JCLOUDS-1174
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1174
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.2
>Reporter: Ryan MacDowell
> Labels: azureblob, transient
> Attachments: DirectoryExistsTest.java
>
>
> If you create a directory in azureblob or transient, blobexists will return
> true for that directory name. It does not seem to filter out the marker
> blobs. If you create a directory in aws-s3 and call blobexists on that
> directory name it will return false.
> Example code below
> {code}
> import org.jclouds.ContextBuilder;
> import org.jclouds.blobstore.BlobStore;
> import org.jclouds.blobstore.BlobStoreContext;
> import com.amazonaws.auth.AWSCredentials;
> import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
> //Test for equals behavior
> public class DirectoryExistsTest {
> public static void main(String[] args) {
> String containerName = "test.container";
> String testDirectory = "testDirectory";
> AWSCredentials creds = new
> DefaultAWSCredentialsProviderChain().getCredentials();
> //Setup the contexts
> BlobStoreContext transientContext =
> ContextBuilder.newBuilder("transient")
> .credentials(creds.getAWSAccessKeyId(),
> creds.getAWSSecretKey())
> .build(BlobStoreContext.class);
> BlobStoreContext awsS3Context =
> ContextBuilder.newBuilder("aws-s3")
> .credentials(creds.getAWSAccessKeyId(),
> creds.getAWSSecretKey())
> .build(BlobStoreContext.class);
> //Setup the blobstores
> BlobStore transientStore = transientContext.getBlobStore();
> BlobStore awsS3Store = awsS3Context.getBlobStore();
> //Setup the containers
> transientStore.createContainerInLocation(null, containerName);
> awsS3Store.createContainerInLocation(null, containerName);
> //Setup the directories
> transientStore.createDirectory(containerName, testDirectory);
> awsS3Store.createDirectory(containerName, testDirectory);
> System.out.println("Transient directory should exist " +
> transientStore.directoryExists(containerName, testDirectory));
> System.out.println("Transient blob should not exist " +
> transientStore.blobExists(containerName, testDirectory));
> System.out.println("aws-s3 directory should exist " +
> awsS3Store.directoryExists(containerName, testDirectory));
> System.out.println("aws-s3 blob should not exist " +
> awsS3Store.blobExists(containerName, testDirectory));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCLOUDS-1174) Transient and Azure blob do not filter out marker blobs from blob exists
[
https://issues.apache.org/jira/browse/JCLOUDS-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gaul updated JCLOUDS-1174:
-
Labels: azureblob transient (was: )
> Transient and Azure blob do not filter out marker blobs from blob exists
>
>
> Key: JCLOUDS-1174
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1174
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 1.9.2
>Reporter: Ryan MacDowell
> Labels: azureblob, transient
> Attachments: DirectoryExistsTest.java
>
>
> If you create a directory in azureblob or transient, blobexists will return
> true for that directory name. It does not seem to filter out the marker
> blobs. If you create a directory in aws-s3 and call blobexists on that
> directory name it will return false.
> Example code below
> {code}
> import org.jclouds.ContextBuilder;
> import org.jclouds.blobstore.BlobStore;
> import org.jclouds.blobstore.BlobStoreContext;
> import com.amazonaws.auth.AWSCredentials;
> import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
> //Test for equals behavior
> public class DirectoryExistsTest {
> public static void main(String[] args) {
> String containerName = "test.container";
> String testDirectory = "testDirectory";
> AWSCredentials creds = new
> DefaultAWSCredentialsProviderChain().getCredentials();
> //Setup the contexts
> BlobStoreContext transientContext =
> ContextBuilder.newBuilder("transient")
> .credentials(creds.getAWSAccessKeyId(),
> creds.getAWSSecretKey())
> .build(BlobStoreContext.class);
> BlobStoreContext awsS3Context =
> ContextBuilder.newBuilder("aws-s3")
> .credentials(creds.getAWSAccessKeyId(),
> creds.getAWSSecretKey())
> .build(BlobStoreContext.class);
> //Setup the blobstores
> BlobStore transientStore = transientContext.getBlobStore();
> BlobStore awsS3Store = awsS3Context.getBlobStore();
> //Setup the containers
> transientStore.createContainerInLocation(null, containerName);
> awsS3Store.createContainerInLocation(null, containerName);
> //Setup the directories
> transientStore.createDirectory(containerName, testDirectory);
> awsS3Store.createDirectory(containerName, testDirectory);
> System.out.println("Transient directory should exist " +
> transientStore.directoryExists(containerName, testDirectory));
> System.out.println("Transient blob should not exist " +
> transientStore.blobExists(containerName, testDirectory));
> System.out.println("aws-s3 directory should exist " +
> awsS3Store.directoryExists(containerName, testDirectory));
> System.out.println("aws-s3 blob should not exist " +
> awsS3Store.blobExists(containerName, testDirectory));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-1177) Azure object encryption
[ https://issues.apache.org/jira/browse/JCLOUDS-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486319#comment-15486319 ] Andrew Gaul commented on JCLOUDS-1177: -- [~jasonpoon] I believe you would add a new method to `AzureBlobClient` which updates the storage accounts properties since Azure does not support per-object encryption: https://msdn.microsoft.com/en-us/library/azure/mt163564.aspx > Azure object encryption > --- > > Key: JCLOUDS-1177 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1177 > Project: jclouds > Issue Type: New Feature > Components: jclouds-blobstore >Affects Versions: 1.9.2 >Reporter: Andrew Gaul >Assignee: Rita Zhang > Labels: azureblob > > Microsoft announced general availability of object encryption: > https://blogs.msdn.microsoft.com/windowsazurestorage/2016/09/12/announcing-the-general-availability-of-storage-service-encryption-for-data-at-rest/ > jclouds should support this. [~ritazh] Could you look into this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jclouds/jclouds-karaf] JCLOUDS-1005: Add Backblaze B2 (#82)
You can view, comment on, or merge this pull request online at: https://github.com/jclouds/jclouds-karaf/pull/82 -- Commit Summary -- * JCLOUDS-1005: Add Backblaze B2 -- File Changes -- M feature/pom.xml (1) M feature/src/main/resources/feature.xml (5) M itests/src/test/java/org/jclouds/karaf/itests/MiscFeaturesInstallationTest.java (5) -- Patch Links -- https://github.com/jclouds/jclouds-karaf/pull/82.patch https://github.com/jclouds/jclouds-karaf/pull/82.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-karaf/pull/82
