[jira] [Commented] (JCLOUDS-857) Tests fail due to Incorrect number of names on @org.jclouds.json.SerializedNames(value=[loadSucceeded, loadErrors, testPassed, testFailures])
[
https://issues.apache.org/jira/browse/JCLOUDS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14617690#comment-14617690
]
ASF subversion and git services commented on JCLOUDS-857:
-
Commit 1c1cfffd5d0e58ec8b8ad1e3d307c9d0ffaeb000 in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=1c1cfff ]
JCLOUDS-857: remove spurious annotation
Multiple constructors annotated with @SerializedNames confuses
NamingStrategies.translateName and causes failures with newer JDK.
Since the second constructor does not need this annotation we remote
it.
Tests fail due to Incorrect number of names on
@org.jclouds.json.SerializedNames(value=[loadSucceeded, loadErrors,
testPassed, testFailures])
-
Key: JCLOUDS-857
URL: https://issues.apache.org/jira/browse/JCLOUDS-857
Project: jclouds
Issue Type: Bug
Components: jclouds-labs-google
Affects Versions: 1.8.1
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: google-compute-engine
Attachments: log.txt
Some GCE tests fail due to Incorrect number of names on
@org.jclouds.json.SerializedNames(value=[loadSucceeded, loadErrors,
testPassed, testFailures]) when using newer versions of Java:
{noformat}
$ mvn clean test -pl google-compute-engine
-Dtest=ParseUrlMapValidateTest,UrlMapApiMockTest
...
Failed tests:
ParseUrlMapValidateTestBaseParserTest.test:69 » HttpResponse Error parsing
in...
UrlMapApiMockTest.validate:115 » IllegalState Incorrect number of names on
@or...
{noformat}
These tests pass with JDK 7u72 and 8u25 but fail with 7u76 and 8u31.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14617763#comment-14617763 ] ASF subversion and git services commented on JCLOUDS-930: - Commit 6d27fbb18ac682df4579c98b7c3f3fefe8ca11e6 in jclouds's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=6d27fbb ] JCLOUDS-930: Handle subdir entries correctly. When listing blobs, Swift returns an array of subdir entries for every common prefix. The openstack-swift provider needs to process such entries and add them to the result set. The subdir array is an array of strings, so additional metadata needs to be added to the objects (bogus ETag, bogus LastModifiedDate, and so on). When directory marker blobs are used, this means that potential _two_ entries are generated for every directory if: 1. the delimiter is set and matches the directory blob (e.g. dir/ and delimiter /) 2. there are objects under the directory name (e.g. dir/blob), which will result in results that include common prefixes (subdir) In the above example, we should expect two results: dir and dir/ representing the directory marker blob and the common prefix, respectively. This is caught in the testDirectory integration test. The patch changes the behavior of the Swift provider to correctly handle the results in the subdir stanza and changes the test to expect the directory marker to be returned in the list. Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Assignee: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-956) allocateFloatingIPForNode in Nova
[
https://issues.apache.org/jira/browse/JCLOUDS-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613135#comment-14613135
]
ASF subversion and git services commented on JCLOUDS-956:
-
Commit 14824b6c8c2d2eeeb0fc64a7b6db1406a20deb76 in jclouds's branch
refs/heads/1.9.x from [~andreaturli]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=14824b6 ]
[JCLOUDS-956] synchronizing allocateFloatingIPForNode helps
allocateFloatingIPForNode in Nova
-
Key: JCLOUDS-956
URL: https://issues.apache.org/jira/browse/JCLOUDS-956
Project: jclouds
Issue Type: Bug
Components: jclouds-compute
Affects Versions: 1.9.0
Reporter: Andrea Turli
Assignee: Andrea Turli
Fix For: 2.0.0, 1.9.1
While provisioning more than 1 VM, I sometimes get this error
{noformat}
- {pool:my-pool}
- POST
https://myprovider.com/compute/v2/c8d3c47a466eec25a/os-floating-ips HTTP/1.1
- Accept: application/json
- X-Auth-Token:
AQIC5wM2LY4SfcwG_QdLNpTu70Efa8hQpS3NF8tL4TkBt9I.*AAJTSQACMDIAAlNLABM4NTc5MTY5MTQyOTY1ODU0Mjg2AAJTMQACMDE.*
- Content-Type: application/json
- Content-Length: 27
- Command not considered safe to retry because request method is POST:
[method=org.jclouds.openstack.nova.v2_0.extensions.FloatingIPApi.public
abstract org.jclouds.openstack.nova.v2_0.domain.FloatingIP
org.jclouds.openstack.nova.v2_0.extensions.FloatingIPApi.allocateFromPool(java.lang.String)[PublicNetwork-02],
request=POST https://myprovider/compute/v2/7a466eec25a/os-floating-ips
HTTP/1.1]
- createNodesInGroup(group-89), completed: 0/2, errors: 1, rate: 67349ms/op
java.util.concurrent.ExecutionException:
org.jclouds.http.HttpResponseException: Unexpected end of file from server
connecting to POST
https://cloud.numergy.com/compute/v2/3e00d5716204446c8d3c47a466eec25a/os-floating-ips
HTTP/1.1
at
com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
~[guava-16.0.1.jar:na]
at
com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
~[guava-16.0.1.jar:na]
at
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
~[guava-16.0.1.jar:na]
at
org.jclouds.concurrent.FutureIterables$1.run(FutureIterables.java:123)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_71]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_71]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
Caused by: org.jclouds.http.HttpResponseException: Unexpected end of file
from server connecting to POST
https://cloud.numergy.com/compute/v2/3e00d5716204446c8d3c47a466eec25a/os-floating-ips
HTTP/1.1
at
org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:117)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
~[guava-16.0.1.jar:na]
at com.sun.proxy.$Proxy80.allocateFromPool(Unknown Source) ~[na:na]
at
org.jclouds.openstack.nova.v2_0.compute.functions.AllocateAndAddFloatingIpToNode.allocateFloatingIPForNode(AllocateAndAddFloatingIpToNode.java:112)
~[openstack-nova-1.9.1-20150629.100031-92.jar:1.9.1-SNAPSHOT]
at
org.jclouds.openstack.nova.v2_0.compute.functions.AllocateAndAddFloatingIpToNode.apply(AllocateAndAddFloatingIpToNode.java:83)
~[openstack-nova-1.9.1-20150629.100031-92.jar:1.9.1-SNAPSHOT]
at
org.jclouds.openstack.nova.v2_0.compute.functions.AllocateAndAddFloatingIpToNode.apply(AllocateAndAddFloatingIpToNode.java:55)
~[openstack-nova-1.9.1-20150629.100031-92.jar:1.9.1-SNAPSHOT]
at
com.google.common.util.concurrent.Futures$1.apply(Futures.java:713)
~[guava-16.0.1.jar:na]
at
com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:861)
~[guava-16.0.1.jar:na]
... 3 common
[jira] [Commented] (JCLOUDS-956) allocateFloatingIPForNode in Nova
[
https://issues.apache.org/jira/browse/JCLOUDS-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613134#comment-14613134
]
ASF subversion and git services commented on JCLOUDS-956:
-
Commit 82da165fdd7afc63b31e7c95a28d4a34b55054e7 in jclouds's branch
refs/heads/master from [~andreaturli]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=82da165 ]
[JCLOUDS-956] synchronizing allocateFloatingIPForNode helps
allocateFloatingIPForNode in Nova
-
Key: JCLOUDS-956
URL: https://issues.apache.org/jira/browse/JCLOUDS-956
Project: jclouds
Issue Type: Bug
Components: jclouds-compute
Affects Versions: 1.9.0
Reporter: Andrea Turli
Assignee: Andrea Turli
Fix For: 2.0.0, 1.9.1
While provisioning more than 1 VM, I sometimes get this error
{noformat}
- {pool:my-pool}
- POST
https://myprovider.com/compute/v2/c8d3c47a466eec25a/os-floating-ips HTTP/1.1
- Accept: application/json
- X-Auth-Token:
AQIC5wM2LY4SfcwG_QdLNpTu70Efa8hQpS3NF8tL4TkBt9I.*AAJTSQACMDIAAlNLABM4NTc5MTY5MTQyOTY1ODU0Mjg2AAJTMQACMDE.*
- Content-Type: application/json
- Content-Length: 27
- Command not considered safe to retry because request method is POST:
[method=org.jclouds.openstack.nova.v2_0.extensions.FloatingIPApi.public
abstract org.jclouds.openstack.nova.v2_0.domain.FloatingIP
org.jclouds.openstack.nova.v2_0.extensions.FloatingIPApi.allocateFromPool(java.lang.String)[PublicNetwork-02],
request=POST https://myprovider/compute/v2/7a466eec25a/os-floating-ips
HTTP/1.1]
- createNodesInGroup(group-89), completed: 0/2, errors: 1, rate: 67349ms/op
java.util.concurrent.ExecutionException:
org.jclouds.http.HttpResponseException: Unexpected end of file from server
connecting to POST
https://cloud.numergy.com/compute/v2/3e00d5716204446c8d3c47a466eec25a/os-floating-ips
HTTP/1.1
at
com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299)
~[guava-16.0.1.jar:na]
at
com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)
~[guava-16.0.1.jar:na]
at
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
~[guava-16.0.1.jar:na]
at
org.jclouds.concurrent.FutureIterables$1.run(FutureIterables.java:123)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_71]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_71]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
Caused by: org.jclouds.http.HttpResponseException: Unexpected end of file
from server connecting to POST
https://cloud.numergy.com/compute/v2/3e00d5716204446c8d3c47a466eec25a/os-floating-ips
HTTP/1.1
at
org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:117)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
~[jclouds-core-1.9.1-20150629.094306-95.jar:1.9.1-SNAPSHOT]
at
com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
~[guava-16.0.1.jar:na]
at com.sun.proxy.$Proxy80.allocateFromPool(Unknown Source) ~[na:na]
at
org.jclouds.openstack.nova.v2_0.compute.functions.AllocateAndAddFloatingIpToNode.allocateFloatingIPForNode(AllocateAndAddFloatingIpToNode.java:112)
~[openstack-nova-1.9.1-20150629.100031-92.jar:1.9.1-SNAPSHOT]
at
org.jclouds.openstack.nova.v2_0.compute.functions.AllocateAndAddFloatingIpToNode.apply(AllocateAndAddFloatingIpToNode.java:83)
~[openstack-nova-1.9.1-20150629.100031-92.jar:1.9.1-SNAPSHOT]
at
org.jclouds.openstack.nova.v2_0.compute.functions.AllocateAndAddFloatingIpToNode.apply(AllocateAndAddFloatingIpToNode.java:55)
~[openstack-nova-1.9.1-20150629.100031-92.jar:1.9.1-SNAPSHOT]
at
com.google.common.util.concurrent.Futures$1.apply(Futures.java:713)
~[guava-16.0.1.jar:na]
at
com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:861)
~[guava-16.0.1.jar:na]
... 3 common
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612672#comment-14612672 ] ASF subversion and git services commented on JCLOUDS-930: - Commit bc9cda2e372b7c19242815dbacc3bb015e8dc6ad in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=bc9cda2 ] JCLOUDS-930: Remove bogus dependsOnMethods Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Assignee: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612855#comment-14612855
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 41d598b03f669905ee868021c04154867dc51540 in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=41d598b ]
JCLOUDS-894: Skip multipart tests on Atmos
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-952) azure-compute cannot parse a suspended VM
[ https://issues.apache.org/jira/browse/JCLOUDS-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610586#comment-14610586 ] ASF subversion and git services commented on JCLOUDS-952: - Commit 2eb75b5a30c56201dd9c2e843b8e870479d752f1 in jclouds-labs's branch refs/heads/1.9.x from [~andreaturli] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=2eb75b5 ] [azurecompute] fix JCLOUDS-952 fix RoleInstanceHandler when Role is suspended azure-compute cannot parse a suspended VM - Key: JCLOUDS-952 URL: https://issues.apache.org/jira/browse/JCLOUDS-952 Project: jclouds Issue Type: Bug Components: jclouds-labs Affects Versions: 1.9.0 Reporter: Andrea Turli Assignee: Andrea Turli Labels: easyfix Fix For: 2.0.0, 1.9.1 listNodes fails when the Azure account contains a suspended VM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-952) azure-compute cannot parse a suspended VM
[ https://issues.apache.org/jira/browse/JCLOUDS-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610582#comment-14610582 ] ASF subversion and git services commented on JCLOUDS-952: - Commit 431f07beb91b9c3de7a5bcdb671acc4a8c0906d6 in jclouds-labs's branch refs/heads/master from [~andreaturli] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=431f07b ] [azurecompute] fix JCLOUDS-952 fix RoleInstanceHandler when Role is suspended azure-compute cannot parse a suspended VM - Key: JCLOUDS-952 URL: https://issues.apache.org/jira/browse/JCLOUDS-952 Project: jclouds Issue Type: Bug Components: jclouds-labs Affects Versions: 1.9.0 Reporter: Andrea Turli Assignee: Andrea Turli Labels: easyfix Fix For: 2.0.0, 1.9.1 listNodes fails when the Azure account contains a suspended VM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609297#comment-14609297 ] ASF subversion and git services commented on JCLOUDS-930: - Commit b4bc679d60ff6e8816b42e24d32f1d804a903ddf in jclouds-labs's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=b4bc679 ] JCLOUDS-930: Fixup the test to expect /. After the change to address JCLOUDS-930, the tests need to expect that a trailing slash is present in the common prefixes (the delimiter -- / -- is included). Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Assignee: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609298#comment-14609298 ] ASF subversion and git services commented on JCLOUDS-930: - Commit b4bc679d60ff6e8816b42e24d32f1d804a903ddf in jclouds-labs's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=b4bc679 ] JCLOUDS-930: Fixup the test to expect /. After the change to address JCLOUDS-930, the tests need to expect that a trailing slash is present in the common prefixes (the delimiter -- / -- is included). Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Assignee: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-702) Create ProfitBricks Provider
[ https://issues.apache.org/jira/browse/JCLOUDS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14608246#comment-14608246 ] ASF subversion and git services commented on JCLOUDS-702: - Commit 17a838b28c9625070848bc83cbf007e3e895f937 in jclouds-labs's branch refs/heads/master from [~devcsrj] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=17a838b ] JCLOUDS-702: JClouds ProfitBricks provider - ComputeServiceAdapter Create ProfitBricks Provider Key: JCLOUDS-702 URL: https://issues.apache.org/jira/browse/JCLOUDS-702 Project: jclouds Issue Type: Task Components: jclouds-compute Reporter: Reijhanniel Jearl Campos -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-702) Create ProfitBricks Provider
[ https://issues.apache.org/jira/browse/JCLOUDS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14608244#comment-14608244 ] ASF subversion and git services commented on JCLOUDS-702: - Commit d07fcb17d606a84b5d50180310725d260db3d400 in jclouds-labs's branch refs/heads/1.9.x from [~devcsrj] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=d07fcb1 ] JCLOUDS-702: JClouds ProfitBricks provider - ComputeServiceAdapter Create ProfitBricks Provider Key: JCLOUDS-702 URL: https://issues.apache.org/jira/browse/JCLOUDS-702 Project: jclouds Issue Type: Task Components: jclouds-compute Reporter: Reijhanniel Jearl Campos -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14608633#comment-14608633 ] ASF subversion and git services commented on JCLOUDS-930: - Commit aade18b76d9c78be2a207e54722814907b191bed in jclouds's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=aade18b ] JCLOUDS-930: LocalBlobStore -- marker regression. We should not append a / to the marker when returning list results in the case of directories (RELATIVE_PATH), as the names will already include the delimiter. Added a jclouds test to catch such regressions in the local store in the future. Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Assignee: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14607567#comment-14607567 ] ASF subversion and git services commented on JCLOUDS-930: - Commit 068dbf251817cad8ccfb7d8b7f3060b5d69f5166 in jclouds-labs-google's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=068dbf2 ] JCLOUDS-930: Skip the prefix test in GCS. As the prefix option has not been plumbed down into GCS, we should skip the prefix test. Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Assignee: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-946) The ImageExtension in DigitalOcean only works with the first available location
[ https://issues.apache.org/jira/browse/JCLOUDS-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609088#comment-14609088 ] ASF subversion and git services commented on JCLOUDS-946: - Commit c001f260771bb9242649bbd45c67fa977f039958 in jclouds-labs's branch refs/heads/master from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=c001f26 ] JCLOUDS-946: Properly scope images to the locations where they are available The ImageExtension in DigitalOcean only works with the first available location --- Key: JCLOUDS-946 URL: https://issues.apache.org/jira/browse/JCLOUDS-946 Project: jclouds Issue Type: Bug Components: jclouds-labs Affects Versions: 1.9.0 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean In DigitalOcean, in the ImageToImage function, the location is not being set. That means images are available in all regions. This assumption is not true, as the images created by the image extension (from a Droplet) are only available in the region of the source droplet. This is causing the image extension live test to fail in all regions but NYC1. The resulting image is missing the location id, and the template builder tries to find it in the default location (NYC1). This should be done in the V2 provider. All images have the list of regions where they are available, and jclouds should properly handle that to properly set the location field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606878#comment-14606878 ] ASF subversion and git services commented on JCLOUDS-930: - Commit 497a013c8a395da18a713363209d12b26aeedcae in jclouds's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=497a013 ] JCLOUDS-930: Plumb prefix support down to Azure. Plumbs support for the prefix query option in the Azure provider. This option is not compatible with the directory list option and an exception is thrown if both are set. Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606877#comment-14606877 ] ASF subversion and git services commented on JCLOUDS-930: - Commit 8677ffcb213f4182eee03039431a9562c2eee16a in jclouds's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=8677ffc ] JCLOUDS-930: Implement prefix for LocalBlobStore. Implements prefix support for the local blob store. The patch allows for correctly parsing prefixes that may not terminate with a delimiter (i.e. foo with delimiter / and a key foobar/key, should return foobar/ as the common path) and ones that do (i.e. foo/). NOTE: there is a small change in behavior in this patch. LocalBlobStore used to return the common prefixes without the delimiter character (/). However, other providers do include the delimiter (I checked S3 and Google Cloud Storage) and LocalBlobStore should include it as well. Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606879#comment-14606879 ] ASF subversion and git services commented on JCLOUDS-930: - Commit c409c19ff3faafa77d72e96335d50bb984bf3773 in jclouds's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=c409c19 ] JCLOUDS-930: Plumb prefix support down to S3. Plumbs the ListContainerOptions.prefix setting down to the S3 API. Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606880#comment-14606880 ] ASF subversion and git services commented on JCLOUDS-930: - Commit 1cb082297218532510f32a77a36915a97a09c192 in jclouds's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=1cb0822 ] JCLOUDS-930: Add prefix option to OpenStack Swift. Plumbs the prefix option to the openstack-swift provider. In the process, the support for the recursive option is modified to avoid setting the _path_ parameter, but rather use the delimiter if required (setting the delimiter is sufficient for a non-recursive listing). Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-930) Expose the prefix option when listing a container
[ https://issues.apache.org/jira/browse/JCLOUDS-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606888#comment-14606888 ] ASF subversion and git services commented on JCLOUDS-930: - Commit 1dcd4500ea3c499260b7e42bb520132c0ed6bba2 in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=1dcd450 ] JCLOUDS-930: disable testListDirectoryBlobsS3FS Regression from 8677ffcb213f4182eee03039431a9562c2eee16a. Expose the prefix option when listing a container - Key: JCLOUDS-930 URL: https://issues.apache.org/jira/browse/JCLOUDS-930 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Reporter: Timur Alperovich Assignee: Timur Alperovich Currently, the blob store interface exposes an _inDirectory()_ method to set the directory from which to list blobs. This is implemented through a combination of prefix and delimiter options, namely combining them to retrieve all objects nested under a specific directory (e.g. dir/). jclouds should expose an explicit prefix option to, for example, allow listing objects that all start with a common name. The difference from the existing inDirectory() option is that the prefix would not require the delimiter to be set and could be an arbitrary string. The prefix is an option supported by S3, Swift, Azure, and Google Cloud Storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-613) Implement the DigitalOcean v2 API
[ https://issues.apache.org/jira/browse/JCLOUDS-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604890#comment-14604890 ] ASF subversion and git services commented on JCLOUDS-613: - Commit f36f75789634d5d45346ec5939ff0fa2d84b4b00 in jclouds-labs's branch refs/heads/master from [~ccustine] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=f36f757 ] JCLOUDS-613: Implement the DigitalOcean v2 API Thanks to [~nacx] for pagination, many tests, fixes, and improvements to help push this over the finish line! Implement the DigitalOcean v2 API - Key: JCLOUDS-613 URL: https://issues.apache.org/jira/browse/JCLOUDS-613 Project: jclouds Issue Type: New Feature Components: jclouds-compute Affects Versions: 1.7.3 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: digitalocean Fix For: 2.0.0 DigitalOcean has just released the version 2 of their API. It introduces some major changes as long as many improvements and features that make the API more easy to consume. Version 2 is now a more RESTful API, has a better error population (and hope this will help us get rid of the [custom HTTP response parsing code|https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/http/ResponseStatusFromPayloadHttpCommandExecutorService.java#L89-L128]), and and a more complete domain model. https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-931) createContainersSharedByAllThreads sleeps 10 seconds per container
[ https://issues.apache.org/jira/browse/JCLOUDS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603580#comment-14603580 ] ASF subversion and git services commented on JCLOUDS-931: - Commit e63474a8242aabab38785567d53467dd825d956f in jclouds's branch refs/heads/master from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=e63474a ] JCLOUDS-931: Sleep only after creating containers. jclouds should issue the requests to create all of the containers in the container pool before sleeping. The patch modifies the createContainerAndEnsureEmpty() method to take an additional parameter, which specifies whether awaitConsistency() should be called or not. createContainersSharedByAllThreads sleeps 10 seconds per container -- Key: JCLOUDS-931 URL: https://issues.apache.org/jira/browse/JCLOUDS-931 Project: jclouds Issue Type: Improvement Components: jclouds-blobstore Affects Versions: 1.9.0 Reporter: Andrew Gaul Assignee: Timur Alperovich Instead it should create all containers then sleep for 10 seconds. The current behavior can dominate integration test run-time when running a subset of tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-931) createContainersSharedByAllThreads sleeps 10 seconds per container
[ https://issues.apache.org/jira/browse/JCLOUDS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603581#comment-14603581 ] ASF subversion and git services commented on JCLOUDS-931: - Commit a05f369807a75c16f68837fbe00d03b7dbdcb934 in jclouds's branch refs/heads/1.9.x from [~timuralp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=a05f369 ] JCLOUDS-931: Sleep only after creating containers. jclouds should issue the requests to create all of the containers in the container pool before sleeping. The patch modifies the createContainerAndEnsureEmpty() method to take an additional parameter, which specifies whether awaitConsistency() should be called or not. createContainersSharedByAllThreads sleeps 10 seconds per container -- Key: JCLOUDS-931 URL: https://issues.apache.org/jira/browse/JCLOUDS-931 Project: jclouds Issue Type: Improvement Components: jclouds-blobstore Affects Versions: 1.9.0 Reporter: Andrew Gaul Assignee: Timur Alperovich Instead it should create all containers then sleep for 10 seconds. The current behavior can dominate integration test run-time when running a subset of tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-931) createContainersSharedByAllThreads sleeps 10 seconds per container
[ https://issues.apache.org/jira/browse/JCLOUDS-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603636#comment-14603636 ] ASF subversion and git services commented on JCLOUDS-931: - Commit d28f4eb0460d039116e7239bf3e6a905eddadede in jclouds's branch refs/heads/1.9.x from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=d28f4eb ] JCLOUDS-931: Fix up bad cherry pick createContainersSharedByAllThreads sleeps 10 seconds per container -- Key: JCLOUDS-931 URL: https://issues.apache.org/jira/browse/JCLOUDS-931 Project: jclouds Issue Type: Improvement Components: jclouds-blobstore Affects Versions: 1.9.0 Reporter: Andrew Gaul Assignee: Timur Alperovich Fix For: 2.0.0, 1.9.1 Instead it should create all containers then sleep for 10 seconds. The current behavior can dominate integration test run-time when running a subset of tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-826) JDBC blobstore
[ https://issues.apache.org/jira/browse/JCLOUDS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603761#comment-14603761 ] ASF subversion and git services commented on JCLOUDS-826: - Commit 1c0900f7c0e2a9b3f2a005dbf98caf7a4fcd3a9e in jclouds-labs's branch refs/heads/master from [~rcoedo] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=1c0900f ] JCLOUDS-826: Add blob operations JDBC blobstore -- Key: JCLOUDS-826 URL: https://issues.apache.org/jira/browse/JCLOUDS-826 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.1 Reporter: Andrew Gaul Assignee: Roman Coedo Labels: gsoc2015 jclouds could offer a JDBC blobstore as an alternative to the existing transient and filesystem blobstores. This could store metadata in something like H2 and the actual blob data on a filesystem, similar to Swift. This would work around issues like https://bugs.openjdk.java.net/browse/JDK-8030048 which prevents use of metadata with the filesystem blobstore on Mac OS X. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-936) Move to a LoadingCache for GCE disk-image mapping
[ https://issues.apache.org/jira/browse/JCLOUDS-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602825#comment-14602825 ] ASF subversion and git services commented on JCLOUDS-936: - Commit db6f6efaba2066535ea8eb41ccc6729f24cd108f in jclouds's branch refs/heads/master from [~abayer] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=db6f6ef ] JCLOUDS-936: Switch to LoadingCache for disk-image Move to a LoadingCache for GCE disk-image mapping -- Key: JCLOUDS-936 URL: https://issues.apache.org/jira/browse/JCLOUDS-936 Project: jclouds Issue Type: Improvement Components: jclouds-labs-google Affects Versions: 2.0.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-934) Add support for specifying GCE disk type in compute abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602824#comment-14602824 ] ASF subversion and git services commented on JCLOUDS-934: - Commit f3555cba1b5753f4be954194026d2f307fe37b8f in jclouds's branch refs/heads/master from [~abayer] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=f3555cb ] JCLOUDS-934. Add support for specifying boot disk type in compute service Add support for specifying GCE disk type in compute abstraction Key: JCLOUDS-934 URL: https://issues.apache.org/jira/browse/JCLOUDS-934 Project: jclouds Issue Type: Improvement Components: jclouds-labs-google Affects Versions: 1.9.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0, 1.9.1 If you don't specify otherwise, you get a pd-standard disk for the boot disk of a new instance. The compute abstraction for GCE doesn't specify, so gets the default. This should be changed to allow specifying an arbitrary type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-669) jclouds-cli support for openstack-swift
[
https://issues.apache.org/jira/browse/JCLOUDS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598833#comment-14598833
]
ASF subversion and git services commented on JCLOUDS-669:
-
Commit 72557d90ae596a26d59b8a3adb08bdb760bbb339 in jclouds-karaf's branch
refs/heads/1.9.x from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;h=72557d9 ]
JCLOUDS-669: Add support for openstack-swift
jclouds-cli support for openstack-swift
Key: JCLOUDS-669
URL: https://issues.apache.org/jira/browse/JCLOUDS-669
Project: jclouds
Issue Type: Improvement
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Timur Alperovich
Assignee: Andrew Gaul
Fix For: 2.0.0
I attempted to use the openstack-swift in jclouds-cli and found that it is
not supported:
{quote}
Caused by: java.util.NoSuchElementException: key [openstack-swift] not in the
list of providers or apis: {providers=[digitalocean,
rackspace-cloudservers-us, elastichosts-tor-p, azureblob, openhosting-east1,
rackspace-cloudloadbalancers-uk, softlayer, serverlove-z1-man, aws-ec2,
bluelock-vcloud-zone01, aws-cloudwatch, cloudfiles-uk, elastichosts-lon-b,
elastichosts-lon-p, rackspace-cloudservers-uk, cloudonestorage,
hpcloud-objectstorage, cloudservers-us, rackspace-cloudloadbalancers-us,
elastichosts-lax-p, cloudfiles-us, aws-s3, greenhousedata-element-vcloud,
ninefold-compute, go2cloud-jhb1, ninefold-storage, gogrid, cloudsigma-lvs,
cloudsigma-zrh, skalicloud-sdg-my, cloudservers-uk, elastichosts-sat-p,
hpcloud-compute]
{quote}
Could we add support for openstack-swift in jclouds-cli? Please adjust the
severity as necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-669) jclouds-cli support for openstack-swift
[
https://issues.apache.org/jira/browse/JCLOUDS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598835#comment-14598835
]
ASF subversion and git services commented on JCLOUDS-669:
-
Commit e59f4eb90d88a3db119f26a7103c5a9fd4e09b8b in jclouds-cli's branch
refs/heads/1.9.x from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;h=e59f4eb ]
JCLOUDS-669: Add support for rackspace-cloudfiles
jclouds-cli support for openstack-swift
Key: JCLOUDS-669
URL: https://issues.apache.org/jira/browse/JCLOUDS-669
Project: jclouds
Issue Type: Improvement
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Timur Alperovich
Assignee: Andrew Gaul
Fix For: 2.0.0
I attempted to use the openstack-swift in jclouds-cli and found that it is
not supported:
{quote}
Caused by: java.util.NoSuchElementException: key [openstack-swift] not in the
list of providers or apis: {providers=[digitalocean,
rackspace-cloudservers-us, elastichosts-tor-p, azureblob, openhosting-east1,
rackspace-cloudloadbalancers-uk, softlayer, serverlove-z1-man, aws-ec2,
bluelock-vcloud-zone01, aws-cloudwatch, cloudfiles-uk, elastichosts-lon-b,
elastichosts-lon-p, rackspace-cloudservers-uk, cloudonestorage,
hpcloud-objectstorage, cloudservers-us, rackspace-cloudloadbalancers-us,
elastichosts-lax-p, cloudfiles-us, aws-s3, greenhousedata-element-vcloud,
ninefold-compute, go2cloud-jhb1, ninefold-storage, gogrid, cloudsigma-lvs,
cloudsigma-zrh, skalicloud-sdg-my, cloudservers-uk, elastichosts-sat-p,
hpcloud-compute]
{quote}
Could we add support for openstack-swift in jclouds-cli? Please adjust the
severity as necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-669) jclouds-cli support for openstack-swift
[
https://issues.apache.org/jira/browse/JCLOUDS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598834#comment-14598834
]
ASF subversion and git services commented on JCLOUDS-669:
-
Commit 208f2205e9d81abeb67134c3d464894e80d4ca59 in jclouds-karaf's branch
refs/heads/1.9.x from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;h=208f220 ]
JCLOUDS-669: Add support for rackspace-cloudfiles
jclouds-cli support for openstack-swift
Key: JCLOUDS-669
URL: https://issues.apache.org/jira/browse/JCLOUDS-669
Project: jclouds
Issue Type: Improvement
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Timur Alperovich
Assignee: Andrew Gaul
Fix For: 2.0.0
I attempted to use the openstack-swift in jclouds-cli and found that it is
not supported:
{quote}
Caused by: java.util.NoSuchElementException: key [openstack-swift] not in the
list of providers or apis: {providers=[digitalocean,
rackspace-cloudservers-us, elastichosts-tor-p, azureblob, openhosting-east1,
rackspace-cloudloadbalancers-uk, softlayer, serverlove-z1-man, aws-ec2,
bluelock-vcloud-zone01, aws-cloudwatch, cloudfiles-uk, elastichosts-lon-b,
elastichosts-lon-p, rackspace-cloudservers-uk, cloudonestorage,
hpcloud-objectstorage, cloudservers-us, rackspace-cloudloadbalancers-us,
elastichosts-lax-p, cloudfiles-us, aws-s3, greenhousedata-element-vcloud,
ninefold-compute, go2cloud-jhb1, ninefold-storage, gogrid, cloudsigma-lvs,
cloudsigma-zrh, skalicloud-sdg-my, cloudservers-uk, elastichosts-sat-p,
hpcloud-compute]
{quote}
Could we add support for openstack-swift in jclouds-cli? Please adjust the
severity as necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-941) Add the Content-Type header for filesystem blobstore
[ https://issues.apache.org/jira/browse/JCLOUDS-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595404#comment-14595404 ] ASF subversion and git services commented on JCLOUDS-941: - Commit 37a014ae00788fd8402f444dbfb93c364c9f1a4d in jclouds's branch refs/heads/master from [~ilopmar] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=37a014a ] JCLOUDS-941: Auto-detect filesystem Content-Type When a filesystem blob does not have content metadata and when users set jclouds.filesystem.auto-detect-content-type to tru, probe the file type to return to clients. This is useful when using jclouds to serve an existing filesystem. Add the Content-Type header for filesystem blobstore Key: JCLOUDS-941 URL: https://issues.apache.org/jira/browse/JCLOUDS-941 Project: jclouds Issue Type: Improvement Components: jclouds-blobstore Affects Versions: 2.0.0 Environment: Linux Reporter: Iván López When exposing a filesystem blobstore the Content-Type header is not set. It should be added. This issue is related to https://github.com/andrewgaul/s3proxy/issues/63#issuecomment-113638475 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-941) Add the Content-Type header for filesystem blobstore
[ https://issues.apache.org/jira/browse/JCLOUDS-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596433#comment-14596433 ] ASF subversion and git services commented on JCLOUDS-941: - Commit 38fa41d056af79b012389310e2641b1c938cfeba in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=38fa41d ] JCLOUDS-941: Ignore metadata tests on Mac OS X Also make testOverwriteBlobMetadata consistent with other tests. Add the Content-Type header for filesystem blobstore Key: JCLOUDS-941 URL: https://issues.apache.org/jira/browse/JCLOUDS-941 Project: jclouds Issue Type: Improvement Components: jclouds-blobstore Affects Versions: 2.0.0 Environment: Linux Reporter: Iván López Fix For: 2.0.0 When exposing a filesystem blobstore the Content-Type header is not set. It should be added. This issue is related to https://github.com/andrewgaul/s3proxy/issues/63#issuecomment-113638475 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-936) Move to a LoadingCache for GCE disk-image mapping
[ https://issues.apache.org/jira/browse/JCLOUDS-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593283#comment-14593283 ] ASF subversion and git services commented on JCLOUDS-936: - Commit ed4b89f302906b348e65b4e2f2cecec292d4fd5a in jclouds-labs-google's branch refs/heads/master from [~abayer] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=ed4b89f ] JCLOUDS-936: Switch to LoadingCache for disk-image Move to a LoadingCache for GCE disk-image mapping -- Key: JCLOUDS-936 URL: https://issues.apache.org/jira/browse/JCLOUDS-936 Project: jclouds Issue Type: Improvement Components: jclouds-labs-google Affects Versions: 2.0.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-934) Add support for specifying GCE disk type in compute abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14591501#comment-14591501 ] ASF subversion and git services commented on JCLOUDS-934: - Commit 762b78660d5df482d44b00593b38e9826899aeee in jclouds-labs-google's branch refs/heads/master from [~abayer] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=762b786 ] JCLOUDS-934. Add support for specifying boot disk type in compute service Add support for specifying GCE disk type in compute abstraction Key: JCLOUDS-934 URL: https://issues.apache.org/jira/browse/JCLOUDS-934 Project: jclouds Issue Type: Improvement Components: jclouds-labs-google Affects Versions: 1.9.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0, 1.9.1 If you don't specify otherwise, you get a pd-standard disk for the boot disk of a new instance. The compute abstraction for GCE doesn't specify, so gets the default. This should be changed to allow specifying an arbitrary type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-935) Specify disk type in AttachDisk.InitializeParams as a URL
[ https://issues.apache.org/jira/browse/JCLOUDS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14591509#comment-14591509 ] ASF subversion and git services commented on JCLOUDS-935: - Commit 09eb1c42fdfe77b746e8326610d2013640bef410 in jclouds-labs-google's branch refs/heads/1.9.x from [~abayer] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=09eb1c4 ] JCLOUDS-935. Move AttachDisk.InitializeParams to URI for diskType Note that two tests are failing right now with or without this. Specify disk type in AttachDisk.InitializeParams as a URL - Key: JCLOUDS-935 URL: https://issues.apache.org/jira/browse/JCLOUDS-935 Project: jclouds Issue Type: Bug Components: jclouds-labs-google Affects Versions: 1.9.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0, 1.9.1 According to https://cloud.google.com/compute/docs/reference/latest/instances#resource, the disk type for a boot disk for an instance needs to be specified as a URL, not just the name of the type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-934) Add support for specifying GCE disk type in compute abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14591532#comment-14591532 ] ASF subversion and git services commented on JCLOUDS-934: - Commit f06fb58ccd08d64c9b2fc66c5915df647fabb4ba in jclouds-labs-google's branch refs/heads/1.9.x from [~abayer] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=f06fb58 ] JCLOUDS-934. Add support for specifying boot disk type in compute service Add support for specifying GCE disk type in compute abstraction Key: JCLOUDS-934 URL: https://issues.apache.org/jira/browse/JCLOUDS-934 Project: jclouds Issue Type: Improvement Components: jclouds-labs-google Affects Versions: 1.9.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0, 1.9.1 If you don't specify otherwise, you get a pd-standard disk for the boot disk of a new instance. The compute abstraction for GCE doesn't specify, so gets the default. This should be changed to allow specifying an arbitrary type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-870) google-compute-engine provider doesn't support all available images
[ https://issues.apache.org/jira/browse/JCLOUDS-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583356#comment-14583356 ] ASF subversion and git services commented on JCLOUDS-870: - Commit 3bfa3cea5da0ed54ef1f4ba9e93231191a8538a7 in jclouds-labs-google's branch refs/heads/master from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=3bfa3ce ] Image credentials and project improvements. JCLOUDS-870: Adds the missing projects to the default project list JCLOUDS-861 JCLOUDS-911: Improved the way image OSFamily is parsed and configured the default username for each image type. google-compute-engine provider doesn't support all available images --- Key: JCLOUDS-870 URL: https://issues.apache.org/jira/browse/JCLOUDS-870 Project: jclouds Issue Type: Bug Components: jclouds-compute Reporter: iirekm Labels: google-compute-engine supports only debian and centos, it's all hardcoded in GoogleComputeEngineConstants (!!!), there are much more distros available in GCE, eg Ubuntu, which I can't use -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-861) node creation fails due to ssh failure
[
https://issues.apache.org/jira/browse/JCLOUDS-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583357#comment-14583357
]
ASF subversion and git services commented on JCLOUDS-861:
-
Commit 3bfa3cea5da0ed54ef1f4ba9e93231191a8538a7 in jclouds-labs-google's branch
refs/heads/master from [~nacx]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=3bfa3ce ]
Image credentials and project improvements.
JCLOUDS-870: Adds the missing projects to the default project list
JCLOUDS-861 JCLOUDS-911: Improved the way image OSFamily is parsed and
configured the default username for each image type.
node creation fails due to ssh failure
--
Key: JCLOUDS-861
URL: https://issues.apache.org/jira/browse/JCLOUDS-861
Project: jclouds
Issue Type: Bug
Components: jclouds-labs-google
Reporter: Yaron Rosenbaum
Priority: Minor
Labels: google-compute-engine
I am creating CoreOS nodes, and using cloud-init with them. The cloud-init
takes a while to process.
11:42:32.780 [user thread 3] ERROR jclouds.ssh -
(core:rsa[ssh-agent]@1….2) error acquiring {hostAndPort=1…2:22,
loginUser=core, ssh=null, connectTimeout=6, sessionTimeout=6} (not
retryable): Exhausted available authentication methods
net.schmizz.sshj.userauth.UserAuthException: Exhausted available
authentication methods
I’ve set the following overrides:
overrides.setProperty(ComputeServiceProperties.POLL_INITIAL_PERIOD,
TWENTY_SECONDS);
overrides.setProperty(ComputeServiceProperties.POLL_MAX_PERIOD,
TWENTY_SECONDS);
// 18 retries of 15 seconds -- 4.5 min
overrides.setProperty(Constants.PROPERTY_MAX_RETRIES, 6);
overrides.setProperty(Constants.PROPERTY_RETRY_DELAY_START, 15);
These overrides had no effect.
overrides.setProperty(jclouds.ssh.max-retries, 100);
overrides.setProperty(jclouds.ssh.retry-auth, true);
These overrides worked - ssh retries for 100 times, but: the sleep time
between retries is 2s (which should be exponential backoff, and configurable)
and - eventually locks down the ssh agent for too many retries
(the ssh agent is up, it's only that the ssh key was not installed yet...)
My workaround is to install ssh keys as part of cloud-init, and then
everything works ok, but this is a serious bug, and this workaround will not
work in all cases.
This MAY be related to:
https://github.com/jclouds/jclouds-labs-google/pull/118
PS.
I setup cloud-init by setting user metadata “user-data”=the content of the
cloud-init.yaml file.
cloud-init works, node IS accessible via ssh, and my unit files are up and
running.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-911) Jclouds cannot create CentOS in Google Compute Engine
[ https://issues.apache.org/jira/browse/JCLOUDS-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583358#comment-14583358 ] ASF subversion and git services commented on JCLOUDS-911: - Commit 3bfa3cea5da0ed54ef1f4ba9e93231191a8538a7 in jclouds-labs-google's branch refs/heads/master from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=3bfa3ce ] Image credentials and project improvements. JCLOUDS-870: Adds the missing projects to the default project list JCLOUDS-861 JCLOUDS-911: Improved the way image OSFamily is parsed and configured the default username for each image type. Jclouds cannot create CentOS in Google Compute Engine - Key: JCLOUDS-911 URL: https://issues.apache.org/jira/browse/JCLOUDS-911 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 2.0.0 Reporter: Ruben Rubio Rey Priority: Critical Jclouds cannot create CentOS instances in Google Compute Engine. By default GCE uses the root user to log into the server, and CentOS instances in GCE does not PermitRootLogin at sshd_config. Therefore it fails at org.jclouds.compute.internal.BaseComputeService.createNodesInGroup(BaseComputeService.java:222) because of AuthorizationException. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-935) Specify disk type in AttachDisk.InitializeParams as a URL
[ https://issues.apache.org/jira/browse/JCLOUDS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583625#comment-14583625 ] ASF subversion and git services commented on JCLOUDS-935: - Commit ba3c710b3b3d176fa4ba288559a8a6e99a14951f in jclouds-labs-google's branch refs/heads/master from [~abayer] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=ba3c710 ] JCLOUDS-935. Move AttachDisk.InitializeParams to URI for diskType Note that two tests are failing right now with or without this. Specify disk type in AttachDisk.InitializeParams as a URL - Key: JCLOUDS-935 URL: https://issues.apache.org/jira/browse/JCLOUDS-935 Project: jclouds Issue Type: Bug Components: jclouds-labs-google Affects Versions: 1.9.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0, 1.9.1 According to https://cloud.google.com/compute/docs/reference/latest/instances#resource, the disk type for a boot disk for an instance needs to be specified as a URL, not just the name of the type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-904) Using ContextBuilder to build new aws-s3 context throws NoClassDefFoundError
[
https://issues.apache.org/jira/browse/JCLOUDS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581819#comment-14581819
]
ASF subversion and git services commented on JCLOUDS-904:
-
Commit a809c11a6065951f5aea48bc4a6048986cd0586a in jclouds's branch
refs/heads/master from [~agrz]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=a809c11 ]
JCLOUDS-904 Fixing OSGi Header by adding org.jclouds.io import
Using ContextBuilder to build new aws-s3 context throws NoClassDefFoundError
Key: JCLOUDS-904
URL: https://issues.apache.org/jira/browse/JCLOUDS-904
Project: jclouds
Issue Type: Bug
Components: jclouds-blobstore
Affects Versions: 1.9.0
Environment: Karaf OSGi Container
Reporter: Sebastian Lütge
Priority: Critical
Labels: regression
Following the steps of the quickstart
{code}context = ContextBuilder.newBuilder(aws-s3)
.credentials(accesskeyid, secretaccesskey)
.buildView(BlobStoreContext.class);{code}
using version 1.9.0 creates a NoClassDefFoundError when calling buildView():
{code}java.lang.NoClassDefFoundError: org.jclouds.io.Payload not found by
aws-s3 [77]
at com.sun.proxy.$Proxy45.clinit(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_45]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_45]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_45]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_45]
at java.lang.reflect.Proxy.newInstance(Proxy.java:748)[:1.7.0_45]
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:739)[:1.7.0_45]
at
org.jclouds.rest.config.AnnotatedHttpApiProvider.get(AnnotatedHttpApiProvider.java:45)
at
com.google.inject.internal.BoundProviderFactory.get(BoundProviderFactory.java:55)
at
com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)
at com.google.inject.spi.ProviderLookup$1.get(ProviderLookup.java:89)
at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:98)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:65)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)
at com.google.inject.spi.ProviderLookup$1.get(ProviderLookup.java:89)
at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:98)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:65)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)
at com.google.inject.spi.ProviderLookup$1.get(ProviderLookup.java:89)
at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:98)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
[jira] [Commented] (JCLOUDS-904) Using ContextBuilder to build new aws-s3 context throws NoClassDefFoundError
[
https://issues.apache.org/jira/browse/JCLOUDS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581830#comment-14581830
]
ASF subversion and git services commented on JCLOUDS-904:
-
Commit b1231257fd8410815f0cf5d4b900d8dfe0be4085 in jclouds's branch
refs/heads/1.9.x from [~agrz]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=b123125 ]
JCLOUDS-904 Fixing OSGi Header by adding org.jclouds.io import
Using ContextBuilder to build new aws-s3 context throws NoClassDefFoundError
Key: JCLOUDS-904
URL: https://issues.apache.org/jira/browse/JCLOUDS-904
Project: jclouds
Issue Type: Bug
Components: jclouds-blobstore
Affects Versions: 1.9.0
Environment: Karaf OSGi Container
Reporter: Sebastian Lütge
Priority: Critical
Labels: regression
Following the steps of the quickstart
{code}context = ContextBuilder.newBuilder(aws-s3)
.credentials(accesskeyid, secretaccesskey)
.buildView(BlobStoreContext.class);{code}
using version 1.9.0 creates a NoClassDefFoundError when calling buildView():
{code}java.lang.NoClassDefFoundError: org.jclouds.io.Payload not found by
aws-s3 [77]
at com.sun.proxy.$Proxy45.clinit(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_45]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_45]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_45]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_45]
at java.lang.reflect.Proxy.newInstance(Proxy.java:748)[:1.7.0_45]
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:739)[:1.7.0_45]
at
org.jclouds.rest.config.AnnotatedHttpApiProvider.get(AnnotatedHttpApiProvider.java:45)
at
com.google.inject.internal.BoundProviderFactory.get(BoundProviderFactory.java:55)
at
com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)
at com.google.inject.spi.ProviderLookup$1.get(ProviderLookup.java:89)
at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:98)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:65)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)
at com.google.inject.spi.ProviderLookup$1.get(ProviderLookup.java:89)
at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:98)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:65)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)
at
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)
at com.google.inject.spi.ProviderLookup$1.get(ProviderLookup.java:89)
at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:98)
at
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at
[jira] [Commented] (JCLOUDS-921) Can not ssh with key and sudo password
[ https://issues.apache.org/jira/browse/JCLOUDS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581845#comment-14581845 ] ASF subversion and git services commented on JCLOUDS-921: - Commit 7e1838afbba4028bf47f722f08d4e4bd289c0d0a in jclouds's branch refs/heads/1.9.x from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=7e1838a ] JCLOUDS-921 prioritise key over password in SessionConnection Can not ssh with key and sudo password -- Key: JCLOUDS-921 URL: https://issues.apache.org/jira/browse/JCLOUDS-921 Project: jclouds Issue Type: Bug Affects Versions: 1.9.0 Reporter: Stuart Hendren If keyboard interactive login is not allowed on the box but the user also requires a sudo password the ssh fails as it prioritises the password. If you remove the password then the sudo fails in the SudoAwareInitManager. It would seem better to prioritise the key over the password in SSHClientConnection or possibly try both if they are both present, and the first fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-921) Can not ssh with key and sudo password
[ https://issues.apache.org/jira/browse/JCLOUDS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581844#comment-14581844 ] ASF subversion and git services commented on JCLOUDS-921: - Commit f88acd67c0b26742b1f50d0bbd57a6733060ad2c in jclouds's branch refs/heads/1.9.x from [~hendrens] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=f88acd6 ] JCLOUDS-921 prioritise key over password in SSHClientConnection From ticket: If keyboard interactive login is not allowed on the box but the user also requires a sudo password the ssh fails as it prioritises the password. If you remove the password then the sudo fails in the SudoAwareInitManager. It would seem better to prioritise the key over the password in SSHClientConnection or possibly try both if they are both present, and the first fails. This commit swaps the order of the if else check to use the ssh key if present. Can not ssh with key and sudo password -- Key: JCLOUDS-921 URL: https://issues.apache.org/jira/browse/JCLOUDS-921 Project: jclouds Issue Type: Bug Affects Versions: 1.9.0 Reporter: Stuart Hendren If keyboard interactive login is not allowed on the box but the user also requires a sudo password the ssh fails as it prioritises the password. If you remove the password then the sudo fails in the SudoAwareInitManager. It would seem better to prioritise the key over the password in SSHClientConnection or possibly try both if they are both present, and the first fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-925) GCE ComputeServiceAdapter should support suspendNode and resumeNode
[ https://issues.apache.org/jira/browse/JCLOUDS-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14579006#comment-14579006 ] ASF subversion and git services commented on JCLOUDS-925: - Commit 69909642daafc036a90417fb6546bebb7327cb85 in jclouds-labs-google's branch refs/heads/1.9.x from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=6990964 ] JCLOUDS-925: Add support to start and stop instances in the ComputeService GCE ComputeServiceAdapter should support suspendNode and resumeNode --- Key: JCLOUDS-925 URL: https://issues.apache.org/jira/browse/JCLOUDS-925 Project: jclouds Issue Type: Sub-task Affects Versions: 1.9.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0, 1.9.1 GCE has support for stop/start actions for instances, but suspendNode and resumeNode in GoogleComputeEngineComputeServiceAdapter just throw UnsupportedOperationException. That should be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577595#comment-14577595
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 4f6af133291148216ab029a4c712fdf1f80fccbe in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=4f6af13 ]
JCLOUDS-894: Swift portable MPU improvements
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-925) GCE ComputeServiceAdapter should support suspendNode and resumeNode
[ https://issues.apache.org/jira/browse/JCLOUDS-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577256#comment-14577256 ] ASF subversion and git services commented on JCLOUDS-925: - Commit a3cb4490f0304ee56c3923d38067fddf8e69e065 in jclouds-labs-google's branch refs/heads/master from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=a3cb449 ] JCLOUDS-925: Add support to start and stop instances in the ComputeService GCE ComputeServiceAdapter should support suspendNode and resumeNode --- Key: JCLOUDS-925 URL: https://issues.apache.org/jira/browse/JCLOUDS-925 Project: jclouds Issue Type: Sub-task Affects Versions: 1.9.0 Reporter: Andrew Bayer Assignee: Andrew Bayer Fix For: 2.0.0, 1.9.1 GCE has support for stop/start actions for instances, but suspendNode and resumeNode in GoogleComputeEngineComputeServiceAdapter just throw UnsupportedOperationException. That should be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576622#comment-14576622
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 04c4d5c916eee9fc54e0ae867a997bcda5e28032 in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=04c4d5c ]
JCLOUDS-894: Odds and ends for other providers
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576620#comment-14576620
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit ae157991baea78f385acdbae4a956c0bf3c01e8d in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=ae15799 ]
JCLOUDS-894: Add portable multipart upload for S3
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576618#comment-14576618
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit f14514c06826500e64d7253954fa2fc4deba2654 in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=f14514c ]
JCLOUDS-894: Add portable multipart upload
This unifies the provider multipart upload code paths and removes code
duplication.
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576619#comment-14576619
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 794b385c9821e5f71a211e238cad06469a132355 in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=794b385 ]
JCLOUDS-894: Add portable multipart upload for Azure
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14576621#comment-14576621
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 9a02157a7fd592edc549611b720c3522c5312a9c in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=9a02157 ]
JCLOUDS-894: Add portable multipart upload for Swift
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-912) GCS uploads with InputStream payloads are not working
[
https://issues.apache.org/jira/browse/JCLOUDS-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14569519#comment-14569519
]
ASF subversion and git services commented on JCLOUDS-912:
-
Commit 1a64a1f0fe2895cba5af810b4747438737439fcd in jclouds's branch
refs/heads/1.9.x from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=1a64a1f ]
JCLOUDS-912: Implement RandomInputStream.close
Prevent reading closed RandomInputStream.
GCS uploads with InputStream payloads are not working
-
Key: JCLOUDS-912
URL: https://issues.apache.org/jira/browse/JCLOUDS-912
Project: jclouds
Issue Type: Bug
Components: jclouds-labs-google
Affects Versions: 1.9.0
Environment: Ubuntu 14.04.2 LTS 64-bit
java version 1.7.0_76
Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
Reporter: Ben Piper
Labels: google-cloud-storage
It seems that Payloads based on an InputStream are not currently working with
the google-cloud-storage API, either with simpleUpload or multipartUpload.
The stream is getting closed before a single byte is read for transmission to
the GCS endpoint.
The payload in the request object is first initialised when
GeneratedHttpRequest.Builder.build is called in
RestAnnotationProcessor.apply, and then setPayload is later called on the
HttpRequest object by MultipartUploadBinder (or UploadBinder in the case of
simpleUpload), causing the originally supplied InputStream to be closed.
The setPayload call in UploadBinder.bindToRequest seems redundant, if the
payload has already been set when the request object was built.
MultipartUploadBinder.bindToRequest wraps the original payload in a
MultipartForm, but the stream in the media part will still end up being
closed by the setPayload call. At face value, it doesn't seem like
MapBinder.bindToRequest is an appropriate place to call setPayload unless it
is legitimate to completely replace the original payload (rather than wrap
it) - or at least if it has to mutate the payload property of the request
object, then it needs some way of doing it that doesn't result in the
originally supplied Payload being 'released'.
The simplest way of reproducing this is probably just to add a new
integration test, similar to ObjectApiLiveTest.testMultipartJpegUpload, but
using a FileInputStream based Payload rather than a ByteSource one.
Relevant portion of stack trace is below.
{code}
Caused by: java.io.IOException: Stream already closed
at org.jvnet.mimepull.DataHead$ReadMultiStream.fetch(DataHead.java:248)
~[mimepull-1.9.3.jar:1.9.3]
at org.jvnet.mimepull.DataHead$ReadMultiStream.read(DataHead.java:219)
~[mimepull-1.9.3.jar:1.9.3]
at java.io.SequenceInputStream.read(SequenceInputStream.java:208)
~[na:1.7.0_76]
at java.io.SequenceInputStream.read(SequenceInputStream.java:211)
~[na:1.7.0_76]
at java.io.InputStream.read(InputStream.java:101) ~[na:1.7.0_76]
at com.google.common.io.ByteStreams.copy(ByteStreams.java:175)
~[guava-16.0.1.jar:na]
at
org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.writePayloadToConnection(JavaUrlHttpCommandExecutorService.java:297)
~[jclouds-core-1.9.0.jar:1.9.0]
at
org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:170)
~[jclouds-core-1.9.0.jar:1.9.0]
at
org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:64)
~[jclouds-core-1.9.0.jar:1.9.0]
at
org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:91)
~[jclouds-core-1.9.0.jar:1.9.0]
at
org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90)
~[jclouds-core-1.9.0.jar:1.9.0]
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73)
~[jclouds-core-1.9.0.jar:1.9.0]
at
org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44)
~[jclouds-core-1.9.0.jar:1.9.0]
at
org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
~[jclouds-core-1.9.0.jar:1.9.0]
at
com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
~[guava-16.0.1.jar:na]
at com.sun.proxy.$Proxy120.multipartUpload(Unknown Source) ~[na:na]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-906) Expose and propagate service accounts in node creation
[
https://issues.apache.org/jira/browse/JCLOUDS-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14570008#comment-14570008
]
ASF subversion and git services commented on JCLOUDS-906:
-
Commit 0e3263e0bd879089630a35cc9d33595a65691e8a in jclouds-labs-google's branch
refs/heads/master from [~broudy]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=0e3263e ]
JCLOUDS-906: Add ServiceAccounts to GoogleComputeEngineTemplateOptions
Expose and propagate service accounts in node creation
--
Key: JCLOUDS-906
URL: https://issues.apache.org/jira/browse/JCLOUDS-906
Project: jclouds
Issue Type: Improvement
Components: jclouds-labs-google
Reporter: Pedro Ribeiro
Google Compute Engine instances should be provided with a set of permissions
in the form of a serviceAccounts field at the moment of node creation.
Missing to do so may block the instance from being able to serve its intended
purpose.
[PR 110|https://github.com/jclouds/jclouds-labs-google/pull/110] introduced a
{{serviceAccounts}} field in the NewInstance class, but the support is
incomplete. Some of the wiring is still missing and a way to propagate these
values.
This could probably be easily done by extending GCETemplateOptions as
previously suggested.
Relates to [these
comments|https://github.com/jclouds/jclouds-labs-google/pull/110#issuecomment-101741868].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14568185#comment-14568185
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 9c2d5ce954ee7427dce77306800f265e0e28cf53 in jclouds-labs-google's branch
refs/heads/master from [~broudy]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=9c2d5ce ]
JCLOUDS-894: Disable MultipartUploads tests
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-908) BaseComputeService#listNodes throwing an exception
[
https://issues.apache.org/jira/browse/JCLOUDS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14560662#comment-14560662
]
ASF subversion and git services commented on JCLOUDS-908:
-
Commit f29ac6d6af755f3b9852053b3e41a4317956387a in jclouds-labs-google's branch
refs/heads/1.9.x from [~broudy]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=f29ac6d ]
JCLOUDS-908: Temporary fix to exception thrown in InstanceToNodeMetadata due to
instance names
BaseComputeService#listNodes throwing an exception
--
Key: JCLOUDS-908
URL: https://issues.apache.org/jira/browse/JCLOUDS-908
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs-google
Affects Versions: 1.8.1, 1.9.0
Reporter: Pedro Ribeiro
If I have an instance named j-t2, then when I call
BaseComputeService#listNodes, I get the following error. The 'j' in the
exception seems to result from some manipulation of the instance name.
{code}
Caused by: java.lang.IllegalArgumentException: Object 'j' doesn't match dns
naming constraints. Reason: Can't be null or empty. Length must be 3 to 63
symbols..
at
org.jclouds.predicates.validators.DnsNameValidator.exception(DnsNameValidator.java:74)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:51)
at
org.jclouds.predicates.validators.DnsNameValidator.validate(DnsNameValidator.java:36)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.checkGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:124)
at
org.jclouds.compute.internal.FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.sharedNameForGroup(FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java:120)
at
org.jclouds.googlecomputeengine.compute.functions.FirewallTagNamingConvention$Factory.get(FirewallTagNamingConvention.java:39)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:89)
at
org.jclouds.googlecomputeengine.compute.functions.InstanceInZoneToNodeMetadata.apply(InstanceInZoneToNodeMetadata.java:51)
at
shaded.com.google.common.base.Functions$FunctionComposition.apply(Functions.java:216)
at
shaded.com.google.common.collect.Iterators$8.transform(Iterators.java:799)
at
shaded.com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
at
shaded.com.google.common.collect.Iterators$7.computeNext(Iterators.java:651)
at
shaded.com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
at
shaded.com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
at shaded.com.google.common.collect.Iterators.addAll(Iterators.java:361)
at shaded.com.google.common.collect.Iterables.addAll(Iterables.java:354)
at shaded.com.google.common.collect.Sets.newLinkedHashSet(Sets.java:328)
at
org.jclouds.compute.internal.BaseComputeService.listNodes(BaseComputeService.java:335)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:40)
at com.sun.proxy.$Proxy107.listNodes(Unknown Source)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.getRunningNodesCount(JCloudsCloud.java:389)
at
jenkins.plugins.jclouds.compute.JCloudsCloud.doProvision(JCloudsCloud.java:372)
... 73 more
{code}
*Note*: I have only tested this with version 1.8.1 and I am calling jclouds
from inside a jenkins plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-669) jclouds-cli support for openstack-swift
[
https://issues.apache.org/jira/browse/JCLOUDS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14561891#comment-14561891
]
ASF subversion and git services commented on JCLOUDS-669:
-
Commit 840c06397a07e0a9e43b1007a742582a0a82b012 in jclouds-cli's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;h=840c063 ]
JCLOUDS-669: Add support for openstack-swift
jclouds-cli support for openstack-swift
Key: JCLOUDS-669
URL: https://issues.apache.org/jira/browse/JCLOUDS-669
Project: jclouds
Issue Type: Improvement
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Timur Alperovich
Assignee: Jeremy Daggett
I attempted to use the openstack-swift in jclouds-cli and found that it is
not supported:
{quote}
Caused by: java.util.NoSuchElementException: key [openstack-swift] not in the
list of providers or apis: {providers=[digitalocean,
rackspace-cloudservers-us, elastichosts-tor-p, azureblob, openhosting-east1,
rackspace-cloudloadbalancers-uk, softlayer, serverlove-z1-man, aws-ec2,
bluelock-vcloud-zone01, aws-cloudwatch, cloudfiles-uk, elastichosts-lon-b,
elastichosts-lon-p, rackspace-cloudservers-uk, cloudonestorage,
hpcloud-objectstorage, cloudservers-us, rackspace-cloudloadbalancers-us,
elastichosts-lax-p, cloudfiles-us, aws-s3, greenhousedata-element-vcloud,
ninefold-compute, go2cloud-jhb1, ninefold-storage, gogrid, cloudsigma-lvs,
cloudsigma-zrh, skalicloud-sdg-my, cloudservers-uk, elastichosts-sat-p,
hpcloud-compute]
{quote}
Could we add support for openstack-swift in jclouds-cli? Please adjust the
severity as necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-669) jclouds-cli support for openstack-swift
[
https://issues.apache.org/jira/browse/JCLOUDS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14561892#comment-14561892
]
ASF subversion and git services commented on JCLOUDS-669:
-
Commit 5247e107a8a179394dfaed6f1b8b6f7cd8b89d6d in jclouds-cli's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-cli.git;h=5247e10 ]
JCLOUDS-669: Add support for rackspace-cloudfiles
jclouds-cli support for openstack-swift
Key: JCLOUDS-669
URL: https://issues.apache.org/jira/browse/JCLOUDS-669
Project: jclouds
Issue Type: Improvement
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Timur Alperovich
Assignee: Jeremy Daggett
I attempted to use the openstack-swift in jclouds-cli and found that it is
not supported:
{quote}
Caused by: java.util.NoSuchElementException: key [openstack-swift] not in the
list of providers or apis: {providers=[digitalocean,
rackspace-cloudservers-us, elastichosts-tor-p, azureblob, openhosting-east1,
rackspace-cloudloadbalancers-uk, softlayer, serverlove-z1-man, aws-ec2,
bluelock-vcloud-zone01, aws-cloudwatch, cloudfiles-uk, elastichosts-lon-b,
elastichosts-lon-p, rackspace-cloudservers-uk, cloudonestorage,
hpcloud-objectstorage, cloudservers-us, rackspace-cloudloadbalancers-us,
elastichosts-lax-p, cloudfiles-us, aws-s3, greenhousedata-element-vcloud,
ninefold-compute, go2cloud-jhb1, ninefold-storage, gogrid, cloudsigma-lvs,
cloudsigma-zrh, skalicloud-sdg-my, cloudservers-uk, elastichosts-sat-p,
hpcloud-compute]
{quote}
Could we add support for openstack-swift in jclouds-cli? Please adjust the
severity as necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-669) jclouds-cli support for openstack-swift
[
https://issues.apache.org/jira/browse/JCLOUDS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14561889#comment-14561889
]
ASF subversion and git services commented on JCLOUDS-669:
-
Commit 5589a994655f7273956e7a143e27210f5566869d in jclouds-karaf's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;h=5589a99 ]
JCLOUDS-669: Add support for rackspace-cloudfiles
jclouds-cli support for openstack-swift
Key: JCLOUDS-669
URL: https://issues.apache.org/jira/browse/JCLOUDS-669
Project: jclouds
Issue Type: Improvement
Components: jclouds-cli
Affects Versions: 1.8.0
Reporter: Timur Alperovich
Assignee: Jeremy Daggett
I attempted to use the openstack-swift in jclouds-cli and found that it is
not supported:
{quote}
Caused by: java.util.NoSuchElementException: key [openstack-swift] not in the
list of providers or apis: {providers=[digitalocean,
rackspace-cloudservers-us, elastichosts-tor-p, azureblob, openhosting-east1,
rackspace-cloudloadbalancers-uk, softlayer, serverlove-z1-man, aws-ec2,
bluelock-vcloud-zone01, aws-cloudwatch, cloudfiles-uk, elastichosts-lon-b,
elastichosts-lon-p, rackspace-cloudservers-uk, cloudonestorage,
hpcloud-objectstorage, cloudservers-us, rackspace-cloudloadbalancers-us,
elastichosts-lax-p, cloudfiles-us, aws-s3, greenhousedata-element-vcloud,
ninefold-compute, go2cloud-jhb1, ninefold-storage, gogrid, cloudsigma-lvs,
cloudsigma-zrh, skalicloud-sdg-my, cloudservers-uk, elastichosts-sat-p,
hpcloud-compute]
{quote}
Could we add support for openstack-swift in jclouds-cli? Please adjust the
severity as necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14559547#comment-14559547
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 5095590d602230fd06e099dd31f6a01e2f5d8ebc in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=5095590 ]
JCLOUDS-894: Do not add unnecessary ETag quotes
Previously
AWSS3BlobIntegrationLiveTest.testMultipartUploadMultipleParts failed.
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-897) jclouds breaks with guice 4.0 because rocoto is evil
[ https://issues.apache.org/jira/browse/JCLOUDS-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14555941#comment-14555941 ] ASF subversion and git services commented on JCLOUDS-897: - Commit 136d7ab3d89392835d818ff52819d6d0b3107130 in jclouds-karaf's branch refs/heads/master from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-karaf.git;h=136d7ab ] JCLOUDS-897: Remove the Rocoto dependency jclouds breaks with guice 4.0 because rocoto is evil Key: JCLOUDS-897 URL: https://issues.apache.org/jira/browse/JCLOUDS-897 Project: jclouds Issue Type: Bug Components: jclouds-core Affects Versions: 1.9.0 Reporter: Ben McCann Assignee: Ignasi Barrera Fix For: 2.0.0 Rocoto is a horrible, horrible library. It uses com.google.inject.internal.util.$Preconditions, which you quite obviously should not do. This has been a known issue for years (https://github.com/99soft/rocoto/issues/7), but has not been fixed yet. In fact, the library is completely un-maintained with no commits since 2012. I would love it if we could get rid of this dependency since pulling it in is breaking my project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-897) jclouds breaks with guice 4.0 because rocoto is evil
[ https://issues.apache.org/jira/browse/JCLOUDS-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14554018#comment-14554018 ] ASF subversion and git services commented on JCLOUDS-897: - Commit 7053a7870da15c3996ca0fd6567f398ac9a5dfb0 in jclouds's branch refs/heads/master from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=7053a78 ] JCLOUDS-897: Remove the Rocoto dependency jclouds breaks with guice 4.0 because rocoto is evil Key: JCLOUDS-897 URL: https://issues.apache.org/jira/browse/JCLOUDS-897 Project: jclouds Issue Type: Bug Components: jclouds-core Affects Versions: 1.9.0 Reporter: Ben McCann Assignee: Ignasi Barrera Rocoto is a horrible, horrible library. It uses com.google.inject.internal.util.$Preconditions, which you quite obviously should not do. This has been a known issue for years (https://github.com/99soft/rocoto/issues/7), but has not been fixed yet. In fact, the library is completely un-maintained with no commits since 2012. I would love it if we could get rid of this dependency since pulling it in is breaking my project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-207) Key Pair and Security Groups created by jclouds are not removed when the node is destroyed (via Jclouds)
[ https://issues.apache.org/jira/browse/JCLOUDS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532347#comment-14532347 ] ASF subversion and git services commented on JCLOUDS-207: - Commit 3080965eda23f6a4dcf0c200099b8768a247a18a in jclouds's branch refs/heads/1.9.x from [~hendrens] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=3080965 ] JCLOUDS-207: Key Pair and Security Groups created by jclouds are not removed when the node is destroyed The names created do not match those searched for. They are created in FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java and have are of this form jclouds#I-0#e96. But for example jclouds#I-0#us-east-1#* is used as the search term. Key Pair and Security Groups created by jclouds are not removed when the node is destroyed (via Jclouds) Key: JCLOUDS-207 URL: https://issues.apache.org/jira/browse/JCLOUDS-207 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.6.0 Reporter: Eugen Paraschiv Labels: ec2 Simply stated, the problem is that the nodes that are created in EC2 via jclouds leave a key-pair and a security group each, after they're deleted (also via jclouds). This issue is described in much more detail here: http://www.cloudsoftcorp.com/blog/tidying-up-after-jclouds/ Hopefully it's an easy fix and the operation of first creating and then destroying the node will leave no unnecessary artifacts on the EC2 account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-207) Key Pair and Security Groups created by jclouds are not removed when the node is destroyed (via Jclouds)
[ https://issues.apache.org/jira/browse/JCLOUDS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532349#comment-14532349 ] ASF subversion and git services commented on JCLOUDS-207: - Commit 31749cba5deb387064a60343604c4c3628b4d600 in jclouds's branch refs/heads/master from [~hendrens] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=31749cb ] JCLOUDS-207: Key Pair and Security Groups created by jclouds are not removed when the node is destroyed The names created do not match those searched for. They are created in FormatSharedNamesAndAppendUniqueStringToThoseWhichRepeat.java and have are of this form jclouds#I-0#e96. But for example jclouds#I-0#us-east-1#* is used as the search term. Key Pair and Security Groups created by jclouds are not removed when the node is destroyed (via Jclouds) Key: JCLOUDS-207 URL: https://issues.apache.org/jira/browse/JCLOUDS-207 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.6.0 Reporter: Eugen Paraschiv Labels: ec2 Simply stated, the problem is that the nodes that are created in EC2 via jclouds leave a key-pair and a security group each, after they're deleted (also via jclouds). This issue is described in much more detail here: http://www.cloudsoftcorp.com/blog/tidying-up-after-jclouds/ Hopefully it's an easy fix and the operation of first creating and then destroying the node will leave no unnecessary artifacts on the EC2 account. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-901) Wrong javadocs in cloudstack VolumeApi
[ https://issues.apache.org/jira/browse/JCLOUDS-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532587#comment-14532587 ] ASF subversion and git services commented on JCLOUDS-901: - Commit ac8607fd20c45a9b22b28a75901411c762e8b2f1 in jclouds's branch refs/heads/1.9.x from [~karel.verva...@telenet.be] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=ac8607f ] JCLOUDS-901 Moved CloudStack javadocs around During the rename from *Client to *Api the javadocs were shuffled around. This commit moves them back to the correct methods. Wrong javadocs in cloudstack VolumeApi -- Key: JCLOUDS-901 URL: https://issues.apache.org/jira/browse/JCLOUDS-901 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.7.3, 2.0.0, 1.8.2, 1.9.1 Reporter: Karel Vervaeke Priority: Minor While looking into JCLOUDS-593 I noticed some weirdness in the javadocs. None of their javadoc methods make sense: - docs for createVolumeByDiskOfferingInZone say it's by snapshotId - docs for createVolumeByCustomDOIZ say it's for listing volumes - docs for attachVolume say it's for deleting attached volumes (does that even work?) - docs for detachVolume say it's for attaching volumes etcetera. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-901) Wrong javadocs in cloudstack VolumeApi
[ https://issues.apache.org/jira/browse/JCLOUDS-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532588#comment-14532588 ] ASF subversion and git services commented on JCLOUDS-901: - Commit 2c53ef38a5caf5621fcf74983636fbd00341a674 in jclouds's branch refs/heads/master from [~karel.verva...@telenet.be] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=2c53ef3 ] JCLOUDS-901 Moved CloudStack javadocs around During the rename from *Client to *Api the javadocs were shuffled around. This commit moves them back to the correct methods. Wrong javadocs in cloudstack VolumeApi -- Key: JCLOUDS-901 URL: https://issues.apache.org/jira/browse/JCLOUDS-901 Project: jclouds Issue Type: Bug Components: jclouds-compute Affects Versions: 1.7.3, 2.0.0, 1.8.2, 1.9.1 Reporter: Karel Vervaeke Priority: Minor While looking into JCLOUDS-593 I noticed some weirdness in the javadocs. None of their javadoc methods make sense: - docs for createVolumeByDiskOfferingInZone say it's by snapshotId - docs for createVolumeByCustomDOIZ say it's for listing volumes - docs for attachVolume say it's for deleting attached volumes (does that even work?) - docs for detachVolume say it's for attaching volumes etcetera. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523873#comment-14523873
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 6a2e381c147ec927ba0c30d0e8effa7c56ccc6e5 in jclouds-labs-aws's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-aws.git;h=6a2e381 ]
JCLOUDS-894: Expose GCS multipart operations
Not yet implemented
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523872#comment-14523872
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 4a514501f9e943747259979d01d310174b6c5131 in jclouds-labs-google's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=4a51450 ]
JCLOUDS-894: Expose GCS multipart operations
Not yet implemented
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523871#comment-14523871
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit deeebe46f75dc223b0fe1e217979e4beaf42f2cf in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=deeebe4 ]
JCLOUDS-894: Expose Swift multipart operations
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523869#comment-14523869
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit df3c91ef4ae4cb62b43e122c59d5815ec1c83bfb in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=df3c91e ]
JCLOUDS-894: Expose legacy Swift multipart operations
Not yet implemented
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-894) Expose component operations of multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523870#comment-14523870
]
ASF subversion and git services commented on JCLOUDS-894:
-
Commit 9128ae515f3078862fca64b65be460d63db79f43 in jclouds's branch
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=9128ae5 ]
JCLOUDS-894: Expose S3 multipart operations
Expose component operations of multipart upload
---
Key: JCLOUDS-894
URL: https://issues.apache.org/jira/browse/JCLOUDS-894
Project: jclouds
Issue Type: New Feature
Components: jclouds-blobstore
Affects Versions: 1.9.0
Reporter: Andrew Gaul
Assignee: Andrew Gaul
Labels: multipart
Presently jclouds exposes multipart upload via a simple interface:
{code:java}
blobStore.putBlob(containerName, blob, new PutOptions().multipart(true));
{code}
This does not allow more complicated interactions such as parallel uploads,
uploads with unknown content-lengths, and other interfaces like writing into
an {{OutputStream}}. Further the current {{MultipartUploadStrategy}}
implementations duplicate code across the azureblob, gcs, and s3 providers.
I propose to expose the MPU component operations, e.g., initiate, complete,
abort, and upload part, via the {{BlobStore}} abstraction. This will allow
us to address all the above features.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-852) VMImage Operation Support
[ https://issues.apache.org/jira/browse/JCLOUDS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521597#comment-14521597 ] ASF subversion and git services commented on JCLOUDS-852: - Commit 6b4de9e73209970cb8f678fca53a26018d9dc0b5 in jclouds-labs's branch refs/heads/1.9.x from [~Bhash90] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=6b4de9e ] JCLOUDS-852: Added VMImageOpertaions to Azure Compute VMImage Operation Support - Key: JCLOUDS-852 URL: https://issues.apache.org/jira/browse/JCLOUDS-852 Project: jclouds Issue Type: Sub-task Components: jclouds-compute, jclouds-labs Reporter: Bhathiya Supun Assignee: Bhathiya Supun Fix For: 2.0.0 Support Virtual Machine operations in https://msdn.microsoft.com/en-us/library/azure/dn499771.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-852) VMImage Operation Support
[ https://issues.apache.org/jira/browse/JCLOUDS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521598#comment-14521598 ] ASF subversion and git services commented on JCLOUDS-852: - Commit 882be03ecae0cd89d5c6b58f0e385883c0fafb0a in jclouds-labs's branch refs/heads/master from [~Bhash90] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=882be03 ] JCLOUDS-852: Added VMImageOpertaions to Azure Compute VMImage Operation Support - Key: JCLOUDS-852 URL: https://issues.apache.org/jira/browse/JCLOUDS-852 Project: jclouds Issue Type: Sub-task Components: jclouds-compute, jclouds-labs Reporter: Bhathiya Supun Assignee: Bhathiya Supun Fix For: 2.0.0 Support Virtual Machine operations in https://msdn.microsoft.com/en-us/library/azure/dn499771.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-890) Chef bootstrap fails if no attributes are defined
[ https://issues.apache.org/jira/browse/JCLOUDS-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510734#comment-14510734 ] ASF subversion and git services commented on JCLOUDS-890: - Commit d29424304e335ae258c4ed47eecb73bc14322fa7 in jclouds's branch refs/heads/1.9.x from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=d294243 ] JCLOUDS-890: Prevent NPE when generating the Chef attributes file Chef bootstrap fails if no attributes are defined - Key: JCLOUDS-890 URL: https://issues.apache.org/jira/browse/JCLOUDS-890 Project: jclouds Issue Type: Bug Components: jclouds-chef Affects Versions: 1.9.0 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: chef If no attributes are provided in the bootstrap configuration, a NPE is raised here: https://github.com/jclouds/jclouds/blob/jclouds-1.9.0/apis/chef/src/main/java/org/jclouds/chef/functions/GroupToBootScript.java#L124 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-890) Chef bootstrap fails if no attributes are defined
[ https://issues.apache.org/jira/browse/JCLOUDS-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510737#comment-14510737 ] ASF subversion and git services commented on JCLOUDS-890: - Commit 2b855809a4ef1b87fb17e541442b97a02396fffd in jclouds's branch refs/heads/master from [~nacx] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=2b85580 ] JCLOUDS-890: Prevent NPE when generating the Chef attributes file Chef bootstrap fails if no attributes are defined - Key: JCLOUDS-890 URL: https://issues.apache.org/jira/browse/JCLOUDS-890 Project: jclouds Issue Type: Bug Components: jclouds-chef Affects Versions: 1.9.0 Reporter: Ignasi Barrera Assignee: Ignasi Barrera Labels: chef If no attributes are provided in the bootstrap configuration, a NPE is raised here: https://github.com/jclouds/jclouds/blob/jclouds-1.9.0/apis/chef/src/main/java/org/jclouds/chef/functions/GroupToBootScript.java#L124 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-839) Complete CloudService support
[
https://issues.apache.org/jira/browse/JCLOUDS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14502566#comment-14502566
]
ASF subversion and git services commented on JCLOUDS-839:
-
Commit e4836294dd02f45ad0e963667309c8ec8dd97e57 in jclouds-labs's branch
refs/heads/master from [~Bhash90]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=e483629 ]
JCLOUDS-839: Get Cloud Service Properties Operation Support
Minor change
Added Mock Tests to Cloud Service Properties
Complete CloudService support
-
Key: JCLOUDS-839
URL: https://issues.apache.org/jira/browse/JCLOUDS-839
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs
Reporter: Francesco Chicchiriccò
Assignee: Bhathiya Supun
Fix For: 2.0.0
Complete the support provided in {{CloudServiceApi}} for all operations
described in https://msdn.microsoft.com/en-us/library/azure/ee460812.aspx
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-839) Complete CloudService support
[
https://issues.apache.org/jira/browse/JCLOUDS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14502565#comment-14502565
]
ASF subversion and git services commented on JCLOUDS-839:
-
Commit bc99a70283f4354c8c0265b87ed8d8f193de45b9 in jclouds-labs's branch
refs/heads/1.9.x from [~Bhash90]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=bc99a70 ]
JCLOUDS-839: Get Cloud Service Properties Operation Support
Minor change
Added Mock Tests to Cloud Service Properties
Complete CloudService support
-
Key: JCLOUDS-839
URL: https://issues.apache.org/jira/browse/JCLOUDS-839
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs
Reporter: Francesco Chicchiriccò
Assignee: Bhathiya Supun
Fix For: 2.0.0
Complete the support provided in {{CloudServiceApi}} for all operations
described in https://msdn.microsoft.com/en-us/library/azure/ee460812.aspx
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-873) Complete Network Security Group API implementation
[ https://issues.apache.org/jira/browse/JCLOUDS-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14492125#comment-14492125 ] ASF subversion and git services commented on JCLOUDS-873: - Commit 29435e1c35609fc2d1ae0878243c3af56a8297cc in jclouds-labs's branch refs/heads/master from [~fmartelli] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=29435e1 ] [JCLOUDS-873] Provided network security group operations + some important fixes around live test execution Complete Network Security Group API implementation -- Key: JCLOUDS-873 URL: https://issues.apache.org/jira/browse/JCLOUDS-873 Project: jclouds Issue Type: Sub-task Components: jclouds-labs Reporter: fabio martelli Fix For: 2.0.0 Complete API implementation and provide Mock and Live tests. See [1] for details. [1] https://msdn.microsoft.com/en-us/library/azure/dn913824.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-873) Complete Network Security Group API implementation
[ https://issues.apache.org/jira/browse/JCLOUDS-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14492129#comment-14492129 ] ASF subversion and git services commented on JCLOUDS-873: - Commit 2b69bed1621175ef58ee337c96cb5b9e5b78ab00 in jclouds-labs's branch refs/heads/1.9.x from [~fmartelli] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=2b69bed ] [JCLOUDS-873] Provided network security group operations + some important fixes around live test execution Complete Network Security Group API implementation -- Key: JCLOUDS-873 URL: https://issues.apache.org/jira/browse/JCLOUDS-873 Project: jclouds Issue Type: Sub-task Components: jclouds-labs Reporter: fabio martelli Fix For: 2.0.0 Complete API implementation and provide Mock and Live tests. See [1] for details. [1] https://msdn.microsoft.com/en-us/library/azure/dn913824.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486806#comment-14486806 ] ASF subversion and git services commented on JCLOUDS-651: - Commit 0647ba8c5506a506dde9cadb2db3cb7013afb1be in jclouds's branch refs/heads/1.9.x from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=0647ba8 ] JCLOUDS-651: portable copy object content metadata server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486805#comment-14486805 ] ASF subversion and git services commented on JCLOUDS-651: - Commit 3f2e9f37fd6fad5aa5862467422b0599369bd927 in jclouds's branch refs/heads/1.9.x from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=3f2e9f3 ] JCLOUDS-651: Add @Beta annotations to copy methods server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486807#comment-14486807 ] ASF subversion and git services commented on JCLOUDS-651: - Commit 7c275bdeddfa066a8a2c8b2646ae99cca91bf89c in jclouds's branch refs/heads/1.9.x from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=7c275bd ] JCLOUDS-651: Azure copy object content metadata server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486809#comment-14486809 ] ASF subversion and git services commented on JCLOUDS-651: - Commit f3795651140449c2ddc2ed2c9c36cfc88339ea38 in jclouds's branch refs/heads/1.9.x from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=f379565 ] JCLOUDS-651: Swift copy object content metadata server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486780#comment-14486780 ] ASF subversion and git services commented on JCLOUDS-651: - Commit 0c6052f8030bd17b56747e2e33abdb7c6b70368a in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=0c6052f ] JCLOUDS-651: Swift copy object content metadata server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-884) Do not try to load agentproxies other than netcat over ssh-agent
[ https://issues.apache.org/jira/browse/JCLOUDS-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14487368#comment-14487368 ] ASF subversion and git services commented on JCLOUDS-884: - Commit 7f38520314b4605b032e3a6622c5755f008eb7fc in jclouds's branch refs/heads/master from [~andrewp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=7f38520 ] JCLOUDS-884: Only try netcat over ssh-agent as an agentproxy See http://markmail.org/thread/oto47qk2kzcdtebb Do not try to load agentproxies other than netcat over ssh-agent Key: JCLOUDS-884 URL: https://issues.apache.org/jira/browse/JCLOUDS-884 Project: jclouds Issue Type: Improvement Components: jclouds-drivers Affects Versions: 1.9.0 Reporter: Andrew Phillips Assignee: Andrew Phillips In JCLOUDS-516, we added support for agentproxies, but only really tested for netcat over ssh. The CLI *only* supports this, and other agentproxy implementations (e.g. pageant on Windows) fail there since the dependencies aren't even available. See http://markmail.org/thread/oto47qk2kzcdtebb For now, change this to only try netcat over ssh-agent. If it's possible to include the additional deps in future, we can decide to revert this. See https://github.com/ymnk/jsch-agent-proxy/pull/23 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486779#comment-14486779 ] ASF subversion and git services commented on JCLOUDS-651: - Commit a43dcece16b7eb0569cfe2d96c76221c40356c27 in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=a43dcec ] JCLOUDS-651: S3 copy object content metadata server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-879) Reserved IP address support
[
https://issues.apache.org/jira/browse/JCLOUDS-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14487454#comment-14487454
]
ASF subversion and git services commented on JCLOUDS-879:
-
Commit f0a11c961412562e8a3f126e0f49e587da6bbc96 in jclouds-labs's branch
refs/heads/1.9.x from [~fmartelli]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=f0a11c9 ]
[JCLOUDS-879] Provided reserved IP address operations
Reserved IP address support
---
Key: JCLOUDS-879
URL: https://issues.apache.org/jira/browse/JCLOUDS-879
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs
Reporter: Francesco Chicchiriccò
Assignee: fabio martelli
Labels: azure
Fix For: 2.0.0
Add support for [reserved IP addresses
operations|https://msdn.microsoft.com/en-us/library/azure/dn722420.aspx].
Once done, include management of reserved IP addressed in
{{AzureComputeTemplateOptions}} and {{AzureComputeServiceAdapter}} - which
might conflict with JCLOUDS-853.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-884) Do not try to load agentproxies other than netcat over ssh-agent
[ https://issues.apache.org/jira/browse/JCLOUDS-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14487415#comment-14487415 ] ASF subversion and git services commented on JCLOUDS-884: - Commit 0e2ee14a005ef79efe0c8317fb69d4f71446a37f in jclouds's branch refs/heads/1.9.x from [~andrewp] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=0e2ee14 ] JCLOUDS-884: Only try netcat over ssh-agent as an agentproxy See http://markmail.org/thread/oto47qk2kzcdtebb Do not try to load agentproxies other than netcat over ssh-agent Key: JCLOUDS-884 URL: https://issues.apache.org/jira/browse/JCLOUDS-884 Project: jclouds Issue Type: Improvement Components: jclouds-drivers Affects Versions: 1.9.0 Reporter: Andrew Phillips Assignee: Andrew Phillips Fix For: 2.0.0 In JCLOUDS-516, we added support for agentproxies, but only really tested for netcat over ssh. The CLI *only* supports this, and other agentproxy implementations (e.g. pageant on Windows) fail there since the dependencies aren't even available. See http://markmail.org/thread/oto47qk2kzcdtebb For now, change this to only try netcat over ssh-agent. If it's possible to include the additional deps in future, we can decide to revert this. See https://github.com/ymnk/jsch-agent-proxy/pull/23 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486777#comment-14486777 ] ASF subversion and git services commented on JCLOUDS-651: - Commit 40ba1569370be07dd28e64a7b98240980e1e3860 in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=40ba156 ] JCLOUDS-651: portable copy object content metadata server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486778#comment-14486778 ] ASF subversion and git services commented on JCLOUDS-651: - Commit a761f4cfa199fee39ee74829cdbbbfebf56c0c37 in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=a761f4c ] JCLOUDS-651: Azure copy object content metadata server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-850) Add the live test that extends the BaseTemplateBuilderLiveTest
[ https://issues.apache.org/jira/browse/JCLOUDS-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485306#comment-14485306 ] ASF subversion and git services commented on JCLOUDS-850: - Commit 59f0ae490fdc921944f6abd157d71e07255ed404 in jclouds-labs's branch refs/heads/master from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=59f0ae4 ] [JCLOUDS-850] Providing AzureTemplateBuilderLiveTest Add the live test that extends the BaseTemplateBuilderLiveTest -- Key: JCLOUDS-850 URL: https://issues.apache.org/jira/browse/JCLOUDS-850 Project: jclouds Issue Type: Sub-task Components: jclouds-compute, jclouds-labs Reporter: Ignasi Barrera Assignee: Francesco Chicchiriccò Labels: azure Fix For: 2.0.0 The BaseTemplateBuilderLiveTest provides the contract for the TemplateBuilder. This test is important to detect changes in the images offered by the providers that might impact existing users. All compute providers must implement and have this test passing. The AWS test can be used as a reference test: https://github.com/jclouds/jclouds/blob/master/providers/aws-ec2/src/test/java/org/jclouds/aws/ec2/compute/AWSEC2TemplateBuilderLiveTest.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-850) Add the live test that extends the BaseTemplateBuilderLiveTest
[ https://issues.apache.org/jira/browse/JCLOUDS-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485312#comment-14485312 ] ASF subversion and git services commented on JCLOUDS-850: - Commit 1fc9d0d857c1f18c3c42a23151c92de5db4b617f in jclouds-labs's branch refs/heads/1.9.x from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=1fc9d0d ] [JCLOUDS-850] Providing AzureTemplateBuilderLiveTest Add the live test that extends the BaseTemplateBuilderLiveTest -- Key: JCLOUDS-850 URL: https://issues.apache.org/jira/browse/JCLOUDS-850 Project: jclouds Issue Type: Sub-task Components: jclouds-compute, jclouds-labs Reporter: Ignasi Barrera Assignee: Francesco Chicchiriccò Labels: azure Fix For: 2.0.0 The BaseTemplateBuilderLiveTest provides the contract for the TemplateBuilder. This test is important to detect changes in the images offered by the providers that might impact existing users. All compute providers must implement and have this test passing. The AWS test can be used as a reference test: https://github.com/jclouds/jclouds/blob/master/providers/aws-ec2/src/test/java/org/jclouds/aws/ec2/compute/AWSEC2TemplateBuilderLiveTest.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486396#comment-14486396 ] ASF subversion and git services commented on JCLOUDS-651: - Commit b35295c2380bdfeb60a75e36e037b329996647eb in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=b35295c ] JCLOUDS-651: Add @Beta annotations to copy methods server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-838) Avoid deprecation
[
https://issues.apache.org/jira/browse/JCLOUDS-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14481926#comment-14481926
]
ASF subversion and git services commented on JCLOUDS-838:
-
Commit b9036f5afcdfde0011291fef3e046f977925b518 in jclouds-labs's branch
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=b9036f5 ]
[JCLOUDS-838] Introducing InMemoryKeyManager for PEM-encoded certificate and
private key
Conflicts:
azurecompute/src/main/java/org/jclouds/azurecompute/suppliers/KeyStoreSupplier.java
Avoid deprecation
-
Key: JCLOUDS-838
URL: https://issues.apache.org/jira/browse/JCLOUDS-838
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 2.0.0
Two classes are marked as {{@Deprecated}} but still used:
* {{KeyStoreSupplier}}
* {{SSLContextWithKeysSupplier}}
The TODO comment on top of both says
{quote}
this code needs to be completely refactored. It needs to stop using KeyStore
of at all possible and definitely the local filesystem. Please look at oauth
for examples on how to do this via PEMs.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-849) Add the live test that extends the BaseComputeServiceLiveTest
[ https://issues.apache.org/jira/browse/JCLOUDS-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14481943#comment-14481943 ] ASF subversion and git services commented on JCLOUDS-849: - Commit b134483bc067b0ea5c0dc45fb38119c2ecf621a3 in jclouds-labs's branch refs/heads/1.9.x from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=b134483 ] [JCLOUDS-849] Explicitly setting default test image location to West Europe Add the live test that extends the BaseComputeServiceLiveTest - Key: JCLOUDS-849 URL: https://issues.apache.org/jira/browse/JCLOUDS-849 Project: jclouds Issue Type: Sub-task Components: jclouds-compute, jclouds-labs Reporter: Ignasi Barrera Assignee: fabio martelli Labels: azure Fix For: 2.0.0 The BaseComputeServiceLiveTest provides the contract of the ComputeService abstraction. All compute providers must have a test that extends the base one with all live tests passing. An example implemention can be the DigitalOcean one: https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/compute/strategy/DigitalOceanComputeServiceAdapter.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-849) Add the live test that extends the BaseComputeServiceLiveTest
[ https://issues.apache.org/jira/browse/JCLOUDS-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14481942#comment-14481942 ] ASF subversion and git services commented on JCLOUDS-849: - Commit 367d02d66e9737f84db67fbd2072ced1d60c3026 in jclouds-labs's branch refs/heads/1.9.x from [~fmartelli] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=367d02d ] [JCLOUDS-849] All tests are green in Azure Add the live test that extends the BaseComputeServiceLiveTest - Key: JCLOUDS-849 URL: https://issues.apache.org/jira/browse/JCLOUDS-849 Project: jclouds Issue Type: Sub-task Components: jclouds-compute, jclouds-labs Reporter: Ignasi Barrera Assignee: fabio martelli Labels: azure Fix For: 2.0.0 The BaseComputeServiceLiveTest provides the contract of the ComputeService abstraction. All compute providers must have a test that extends the base one with all live tests passing. An example implemention can be the DigitalOcean one: https://github.com/jclouds/jclouds-labs/blob/master/digitalocean/src/main/java/org/jclouds/digitalocean/compute/strategy/DigitalOceanComputeServiceAdapter.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-838) Avoid deprecation
[
https://issues.apache.org/jira/browse/JCLOUDS-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14481944#comment-14481944
]
ASF subversion and git services commented on JCLOUDS-838:
-
Commit 68935a31b20da35a193848439d1996f98eaadd1e in jclouds-labs's branch
refs/heads/1.9.x from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=68935a3 ]
[JCLOUDS-838] Introducing InMemoryKeyManager for PEM-encoded certificate and
private key
Conflicts:
azurecompute/src/main/java/org/jclouds/azurecompute/suppliers/KeyStoreSupplier.java
Avoid deprecation
-
Key: JCLOUDS-838
URL: https://issues.apache.org/jira/browse/JCLOUDS-838
Project: jclouds
Issue Type: Sub-task
Components: jclouds-compute, jclouds-labs
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 2.0.0
Two classes are marked as {{@Deprecated}} but still used:
* {{KeyStoreSupplier}}
* {{SSLContextWithKeysSupplier}}
The TODO comment on top of both says
{quote}
this code needs to be completely refactored. It needs to stop using KeyStore
of at all possible and definitely the local filesystem. Please look at oauth
for examples on how to do this via PEMs.
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCLOUDS-651) server-side copy in portable abstraction
[ https://issues.apache.org/jira/browse/JCLOUDS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482107#comment-14482107 ] ASF subversion and git services commented on JCLOUDS-651: - Commit d8f48c48b41e229e89c4b5db2641e15003b99277 in jclouds's branch refs/heads/master from [~gaul] [ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=d8f48c4 ] JCLOUDS-651: Copy Swift system metadata server-side copy in portable abstraction Key: JCLOUDS-651 URL: https://issues.apache.org/jira/browse/JCLOUDS-651 Project: jclouds Issue Type: New Feature Components: jclouds-blobstore Affects Versions: 1.8.0 Reporter: Andrew Gaul Assignee: Andrew Gaul jclouds should expose the provider server-side copy functionality in the portable abstraction. When a provider does not support this, jclouds should fall back to client-side copying. Amazon S3 and likely others provide this feature: http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-842) Add suport for operations on Traffic Manager
[ https://issues.apache.org/jira/browse/JCLOUDS-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392433#comment-14392433 ] ASF subversion and git services commented on JCLOUDS-842: - Commit 4e3f19b98ba11ea06c07bb47ef295934e0d280c1 in jclouds-labs's branch refs/heads/master from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=4e3f19b ] [JCLOUDS-842] provided support for traffic manager operations Add suport for operations on Traffic Manager Key: JCLOUDS-842 URL: https://issues.apache.org/jira/browse/JCLOUDS-842 Project: jclouds Issue Type: Sub-task Components: jclouds-labs Reporter: fabio martelli Assignee: fabio martelli Labels: azure Fix For: 2.0.0 Add suport for operations on Traffic Manager. See at https://msdn.microsoft.com/en-us/library/azure/hh758255.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCLOUDS-837) Add support for operations on service certificates
[ https://issues.apache.org/jira/browse/JCLOUDS-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14392434#comment-14392434 ] ASF subversion and git services commented on JCLOUDS-837: - Commit e6a3ce338cb90bd53ae8166b24e498d379a04f09 in jclouds-labs's branch refs/heads/master from [~ilgrosso] [ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs.git;h=e6a3ce3 ] [JCLOUDS-837] added service certificate support Add support for operations on service certificates -- Key: JCLOUDS-837 URL: https://issues.apache.org/jira/browse/JCLOUDS-837 Project: jclouds Issue Type: Sub-task Components: jclouds-labs Reporter: fabio martelli Assignee: fabio martelli Fix For: 2.0.0 Implement support for operation at https://msdn.microsoft.com/en-us/library/azure/ee795178.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
