Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)
Using the HttpClient directly or not will depend on whether we are OK about
including that call as part of the GlanceApi or not. Do we want to expose that
method to users? If it makes sense to expose it, we can add a method to the
GlanceApi that returns the versioned endpoints, and call that method instead of
directly using the HttpClient.
Although it seems that it introduces some overhead, Glance does the right thing
returning a 300. By definition that is the status code to return in this kind
of requests.
And regarding the retry handler, that would be possible. The default retry
strategy for redirects is implemented in the
[RedirectionRetryHandler](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/handlers/RedirectionRetryHandler.java).
As you see, after checking if the request should be retried, it updates the
HttpCommand with the new request to be performed.
You could subclass it, and, if the request is a version negotiation request,
update the HttpCommand accordingly so the request is re-sent to the right
endpoint. For other requests, you can delegate to the super to keep the default
retry logic. Once you have the custom retry handler, you can add the following
to the `GlanceHttpApiModule` to instruct jclouds to use it:
```java
@Override
protected void bindRetryHandlers() {
bind(HttpRetryHandler.class).annotatedWith(Redirection.class).to(YourCustomRetryHandler.class);
}
```
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-38030469
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds » jclouds #922](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/922/) SUCCESS This pull request looks good [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38036047
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Sorry @psiniemi I didn't have time to test this. Will do it today! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38036227
Jenkins build is back to normal : jclouds » jclouds-labs-google #743
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs-google/743/
Jenkins build is back to normal : jclouds » jclouds-chef #838
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-chef/838/
Jenkins build is back to normal : jclouds » jclouds-labs-aws #696
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs-aws/696/
Jenkins build is back to stable : jclouds » jclouds-labs-openstack #928
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs-openstack/928/
Jenkins build is back to normal : jclouds » jclouds-labs #873
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs/873/
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-pull-requests #668](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/668/) UNSTABLE Looks like there's a problem with this pull request --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38037644
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-java-7-pull-requests #1138](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/1138/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38038330
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Thanks for this submission, @psiniemi! I think something went wrong with a recent update? There are now lots of commits and changes in this PR that don't seem to be related to your work. Could you rebase and update? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38048975
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Uh sorry, we use our fork for our development so I pulled in the current jclouds master. Didn't realized they would come into this pull request... I'll try and clean that up. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38050175
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Now it only has only my commits on top of the fork. Should I try and rebase? The master I last pulled had no conflicts... --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38053679
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Rebasing to the latest master is something you'll be asked to do before merging. Feel free to rebase now if you want, as if it works when I test it later today I'll go ahead and merge it :) To avoid this kind of issues, a best practice is to develop the feature in topic branches (and submit the PRs from there) and always keep the master branch of the fork unchanged, using it just to sync with the upstream. Thanks for cleaning up the PR! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38054504
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Now it only has only my commits on top of the fork. Great! This is fine for now. We'll rebase just before merging, most likely... --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38054543
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds » jclouds #923](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/923/) SUCCESS This pull request looks good [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38058229
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
[jclouds-pull-requests #669](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/669/) UNSTABLE Looks like there's a problem with this pull request --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38060588
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
jclouds-pull-requests #669 UNSTABLE Spurious [test failure](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/org.apache.jclouds$jclouds-compute/669/testReport/junit/org.jclouds.compute.callables/BlockUntilInitScriptStatusIsZeroThenReturnOutputTest/testloopUntilTrueOrThrowCancellationExceptionReturnsWhenPredicateIsTrueSecondTimeWhileNotCancelled/) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/312#issuecomment-38061678
Re: [jclouds-labs] Align management and representations with the upstream Guava version (#55)
[jclouds-labs-pull-requests #134](https://jclouds.ci.cloudbees.com/job/jclouds-labs-pull-requests/134/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/55#issuecomment-38075392
Re: [jclouds] Add ssh-agent support via jsch agentproxy (#312)
Ok, I just tested it but I've had to make a few other changes to jclouds to get
it working. Here is the test I did:
* Created a new SSH key pair and set a password to the private key.
* Deployed a node in a cloud provider and installed the created public key on
it, as follows:
```java
ComputeService compute = context.getComputeService();
TemplateOptions options =
compute.templateOptions().authorizePublicKey(publicKey);
compute.createNodesInGroup(ssh, 1, options));
```
* Then tried to run a script on the node (note that the key is still not added
to ssh-agent, so this is supposed to fail), as follows:
```java
// Make sure we don't provide a credential so ssh-agent will be used
LoginCredentials creds =
LoginCredentials.builder().identity(root).noPassword().noPrivateKey().build();
compute.runScriptOnNode(node-id, Statements.exec(touch /tmp/foo),
overrideLoginCredentials(creds).wrapInInitScript(false));
```
This failed with the following error:
Exception in thread main org.jclouds.rest.AuthorizationException:
(root:rsa[ssh-agent]@192.241.153.27:22) (root:rsa[ssh-agent]@192.241.153.27:22)
error acquiring {hostAndPort=192.241.153.27:22, loginUser=root, ssh=null,
connectTimeout=6, sessionTimeout=6} (not retryable): Exhausted
available authentication methods
Caused by: net.schmizz.sshj.userauth.UserAuthException: Exhausted available
authentication methods
... (stacktrace)
Caused by: net.schmizz.sshj.userauth.UserAuthException: publickey auth
failed
... (stacktrace)
* Then I added the key to the ssh agent with `ssh-add`.
* Run the same test again and it succeeded! So the `ssh-agent` changes are
working as expected.
I've had to change the following, to get it working. jclouds performs some
checks to make sure the credentials are present before attempting a connection,
and those restrictions have to be relaxed:
*
[CreateSshClientOncePortIsListeningOnNode](https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/functions/CreateSshClientOncePortIsListeningOnNode.java#L68-L69)
checks that the credentials are present before creating the SSH client.
* We should also consider removing the check from the
[BaseComputeServiceLiveTest.java](https://github.com/jclouds/jclouds/blob/master/compute/src/test/java/org/jclouds/compute/internal/BaseComputeServiceLiveTest.java#L510)
class, to allow to run the live tests using the ssh-agent.
* The same should be considered for [this
test](https://github.com/jclouds/jclouds/blob/master/compute/src/test/java/org/jclouds/compute/internal/BaseComputeServiceLiveTest.java#L231).
@psiniemi Could you add the mentioned changes to the pull request, so the
ssh-agent can be properly used with the Compute Service?
Thanks!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/312#issuecomment-38077166
Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)
Thanks for the useful comments. I hope now it looks better. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/320#issuecomment-38082494
Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)
@@ -70,5 +73,29 @@ public void testExecute() throws Exception {
replay(slicer,client);
[minor] Add a space before client? I know it's not your code, but a bit of
cleanup can't hurt ;-)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320/files#r10761433
Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)
@@ -47,7 +50,7 @@ public void testExecute() throws Exception {
String blobName = test-blob;
long oneMB = 1048576L;
AzureBlobClient client = createMock(AzureBlobClient.class);
- PayloadSlicer slicer = createMock(PayloadSlicer.class);
+ PayloadSlicer slicer = createStrictMock(PayloadSlicer.class);
Hm...would it make more sense to make the one we want to _verify_ strict (i.e.
the client), and leave the _other_ one as a regular mock?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320/files#r10761415
Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)
Many thanks, @markwash! Guess we can't get more official input than that ;-) Looking forward to the changes, @jasdeep-hundal! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-38089395
Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)
[jclouds-java-7-pull-requests #1140](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/1140/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/320#issuecomment-38087104
Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)
[jclouds » jclouds #925](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/925/) SUCCESS This pull request looks good [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/320#issuecomment-38090439
Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)
[jclouds-java-7-pull-requests #1141](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/1141/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/320#issuecomment-38092384
Re: [jclouds-labs-openstack] JCLOUDS-494: Change EndpointParam parser to negotiate version for Glance API (#82)
Many thanks for the feedback! If I undertand it properly, although keystone is not capable of doing content negotiation, the approach currently implemented is correct, isn't it? We'll try to connect to the returned one, and negotiate the version if it returns a 300. Is this version negotiation standard so we can move that logic to the common openstack modules? If not, please correct me, but I think it is better to inspect the body returned in the 300 respo se rather than directly replacing the api version? Thx! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs-openstack/pull/82#issuecomment-38094567
Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)
[jclouds-pull-requests #672](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/672/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/320#issuecomment-38096855
[jira] [Commented] (JCLOUDS-498) PUT object calls fail against Swift with JClouds 1.7.1
[ https://issues.apache.org/jira/browse/JCLOUDS-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940977#comment-13940977 ] Bill Branan commented on JCLOUDS-498: - From the SDSC Cloud folks on a discussion about this issue: Looking at our logs we are getting 499 and 408 errors when you use jclouds/1.7.1 but everything works fine when you use jclouds/1.5.5. 408 and 499 errors typically mean it is a client side error. They suggested that this may be related to JCLOUDS-342. The work done on that issue seems like a possible fix for the 408 errors, but wouldn't address the 499s. PUT object calls fail against Swift with JClouds 1.7.1 -- Key: JCLOUDS-498 URL: https://issues.apache.org/jira/browse/JCLOUDS-498 Project: jclouds Issue Type: Bug Components: jclouds-blobstore Affects Versions: 1.7.1 Environment: Tested on Windows 7 with Java 1.7.0_45 Reporter: Bill Branan Priority: Critical I am attempting to upgrade my application from JClouds 1.5.5 to JClouds 1.7.1. My application connects to an OpenStack Swift storage provider for storing objects. After updating to 1.7.1 all calls seem to work except the calls to store new objects. I've tested listing containers, updating object properties, deleting objects, and deleting containers, and all of these work, but putting a new object does not. The error I see when attempting to put a new object is listed below. I get this error regardless of whether I am using the SwiftClient or the BlobStore interface. I wrote up some tests to isolate the issue. The test for 1.7.1 is here: https://github.com/bbranan/sdsc-tests/tree/master/sdsc-jclouds-1.7.1 The test for 1.5.5 is here: https://github.com/bbranan/sdsc-tests/tree/master/sdsc-jclouds-1.5.5 The tests can be built using ant and run using ant run. The tests work perfectly with 1.5.5, but fail with 1.7.1. (You'll need to enter a couple params at the top of the Java class prior to building.) I should also note that the tests for 1.7.1 pass when I connect to Rackspace, but fail when I connect to SDSC Cloud, so there may be differences between OpenStack Swift providers that are not being accounted for. SDSC Cloud is running the Grizzly version of Swift. The error I see on PUT failure: [java] SEVERE: Cannot retry after server error, command is not replayable: [method=public abstract com.google.common.util.concurrent.ListenableFuture org.jclouds.openstack.swift.CommonSwiftAsyncClient.putObject(java .lang.String,org.jclouds.openstack.swift.domain.SwiftObject)[test-container-1394647640389, [info=[contentDisposition=null, contentEncoding=null, contentLanguage=null, contentLength=null, contentMD5=null, contentType=appl ication/unknown, expires=null]]], request=PUT https://duracloud.auth.cloud.sdsc.edu:443/v1/DURACLOUD_36ef189e-614e-49a9-bb8d-84f66e8553d5/test-container-1394647640389/test-content-blob-1394647701119 HTTP/1.1] [java] PUT failed with error: Read timed out connecting to PUT https://duracloud.auth.cloud.sdsc.edu:443/v1/DURACLOUD_36ef189e-614e-49a9-bb8d-84f66e8553d5/test-container-1394647640389/test-content-blob-13946477011 19 HTTP/1.1 [java] org.jclouds.http.HttpResponseException: Read timed out connecting to PUT https://duracloud.auth.cloud.sdsc.edu:443/v1/DURACLOUD_36ef189e-614e-49a9-bb8d-84f66e8553d5/test-container-1394647640389/test-content-b lob-1394647701119 HTTP/1.1 -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jclouds] Fix Keystone response for testing to not include Glance version (#319)
Closed #319. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/319
Re: [jclouds] Fix Keystone response for testing to not include Glance version (#319)
[Merged](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=22a8b9d04c110789a0a58c479d1525daa700c66b). As soon as [the build](https://jclouds.ci.cloudbees.com/job/jclouds/2560/) finishes and the snapshots are published to the local repo, you should be able to update https://github.com/jclouds/jclouds-labs-openstack/issues/82 accordingly. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/319#issuecomment-38117222
Re: [jclouds] JCLOUDS-184: Improving AzureBlob unit tests for AzureBlobBlockUploadStrategyTest (#320)
+
+ @Test(expectedExceptions = IllegalArgumentException.class)
+ public void testExceededContentLengthLimit() throws Exception {
+ String container = test-container;
+ String blobName = test-blob;
+
+ AzureBlobClient client = createNiceMock(AzureBlobClient.class);
+ PayloadSlicer slicer = createNiceMock(PayloadSlicer.class);
+
+ MutableBlobMetadata metadata = new MutableBlobMetadataImpl();
+ MutableContentMetadata contentMetadata = new
BaseMutableContentMetadata();
+
contentMetadata.setContentLength(MultipartUploadStrategy.MAX_BLOCK_SIZE *
MultipartUploadStrategy.MAX_NUMBER_OF_BLOCKS + 1);
+ metadata.setName(blobName);
+ metadata.setContentMetadata(contentMetadata);
+ Blob blob = new BlobImpl(metadata);
+ Payload payload = new StringPayload(ABCD);
Whoops, missed that! Thanks for spotting, @andrewgaul! Can also be changed in
`testExecute`, please. Code change should be as simple as:
```
ByteSource bytes = ByteSource.wrap(ABCD.getBytes(Charsets.UTF_8));
Payload payload = new ByteSourcePayload(bytes);
```
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/320/files#r10776838
Jenkins build became unstable: jclouds » jclouds-labs-openstack #933
See https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs-openstack/933/
Jenkins build became unstable: jclouds-labs-openstack #308
See https://jclouds.ci.cloudbees.com/job/jclouds-labs-openstack/308/
Jenkins build became unstable: jclouds-labs-openstack » jclouds openstack-glance api #308
See https://jclouds.ci.cloudbees.com/job/jclouds-labs-openstack/org.apache.jclouds.labs$openstack-glance/308/
[jclouds-labs] Fixing CloudSigma tests failing on Java 8 (#56)
Using a map type in the test setup that has a deterministic iteration order You can merge this Pull Request by running: git pull https://github.com/jclouds/jclouds-labs fix-cloudsigma-tests-java-8 Or you can view, comment on it, or merge it online at: https://github.com/jclouds/jclouds-labs/pull/56 -- Commit Summary -- * Fixing CloudSigma tests failing on Java 8 -- File Changes -- M cloudsigma2/src/test/java/org/jclouds/cloudsigma2/CloudSigma2ApiExpectTest.java (10) -- Patch Links -- https://github.com/jclouds/jclouds-labs/pull/56.patch https://github.com/jclouds/jclouds-labs/pull/56.diff --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/56
Re: [jclouds-labs] Fixing CloudSigma tests failing on Java 8 (#56)
Looking good in a [DEV@cloud Java 8 build](https://jclouds.ci.cloudbees.com/view/Java%208/job/fix-cloudsigma-tests-java-8/org.apache.jclouds.labs$cloudsigma2/1/testReport/) (requires login):  --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/56#issuecomment-38128768
Re: [jclouds-labs] Fixing CloudSigma tests failing on Java 8 (#56)
So the Java 8 build succeeded: ``` [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 23:21.651s [INFO] Finished at: Wed Mar 19 22:13:54 EDT 2014 [INFO] Final Memory: 55M/200M [INFO] ``` Now to wait for the PR builders... --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/56#issuecomment-38129137
Re: [jclouds-labs] Fixing CloudSigma tests failing on Java 8 (#56)
[jclouds » jclouds-labs #881](https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs/881/) SUCCESS This pull request looks good [(what's this?)](https://www.cloudbees.com/what-is-buildhive) --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/56#issuecomment-38129315
Re: [jclouds-labs] Fixing CloudSigma tests failing on Java 8 (#56)
[jclouds-labs-pull-requests #135](https://jclouds.ci.cloudbees.com/job/jclouds-labs-pull-requests/135/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/56#issuecomment-38129506
