@timur87: Thanks for fixing the compilation error. Now we're on to a test
failure and a problem with the bundle configuration:
```
Failed tests: getBlob(org.jclouds.orion.OrionApiMockTest): Connection refused
connecting to GET
for three months. I'll be handling it next week.
Thanks, abayer! If you have something like a draft for review, please ping!
ap
I'll dig deeper into that.
Hm. Strange! Thanks for looking into this...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/214#issuecomment-29691969
* @author Alfredo Rainbowbreeze Morresi
*/
public class FilesystemBlobStoreContextModule extends AbstractModule {
@Override
protected void configure() {
-
bind(AsyncBlobStore.class).to(LocalAsyncBlobStore.class).asEagerSingleton();
- // forward all requests from
@@ -41,7 +41,7 @@
import org.jclouds.atmos.domain.UserMetadata;
import org.jclouds.atmos.options.ListOptions;
import org.jclouds.atmos.options.PutOptions;
-import org.jclouds.blobstore.LocalAsyncBlobStore;
+import org.jclouds.blobstore.config.LocalBlobStore;
Any reason why
@@ -72,7 +72,9 @@
private final Closer closer;
@Inject
- private StubAtmosAsyncClient(LocalAsyncBlobStore blobStore,
AtmosObject.Factory objectProvider,
+ private StubAtmosAsyncClient(
+LocalBlobStore blobStore,
+AtmosObject.Factory objectProvider,
@@ -197,7 +203,8 @@ private
StubS3AsyncClient(@Named(Constants.PROPERTY_USER_THREADS) ListeningExecu
final PutObjectOptions options = (nullableOptions.length == 0) ? new
PutObjectOptions() : nullableOptions[0];
if (options.getAcl() != null)
keyToAcl.put(bucketName +
@@ -160,22 +162,26 @@ private
StubS3AsyncClient(@Named(Constants.PROPERTY_USER_THREADS) ListeningExecu
Blob object = source.get(sourceObject);
if (options.getIfMatch() != null) {
if (!object.getMetadata().getETag().equals(options.getIfMatch()))
-
@@ -104,7 +103,8 @@
@Inject
private StubS3AsyncClient(@Named(Constants.PROPERTY_USER_THREADS)
ListeningExecutorService userExecutor,
-LocalAsyncBlobStore blobStore, ConcurrentMapString,
ConcurrentMapString, Blob containerToBlobs,
+LocalBlobStore
}
if (options.getIfUnmodifiedSince() != null) {
Date unmodifiedSince =
dateService.rfc822DateParse(options.getIfUnmodifiedSince());
if
(unmodifiedSince.before(object.getMetadata().getLastModified()))
- return
+ if (!options.isDetailed()) {
+for (StorageMetadata md : contents) {
+ md.getUserMetadata().clear();
+}
+ }
+ }
+
+ return new PageSetImplStorageMetadata(contents, marker);
+
+ }
+
+ private ContainerNotFoundException
@@ -80,9 +79,8 @@
@Inject
MarkersDeleteDirectoryStrategy(
@Named(Constants.PROPERTY_USER_THREADS) ListeningExecutorService
userExecutor,
-AsyncBlobStore ablobstore, BlobStore blobstore) {
+ BlobStore blobstore) {
Formatting? Alignment is not
@@ -72,7 +69,7 @@ public BlobStore getBlobStore() {
@Override
public AsyncBlobStore getAsyncBlobStore() {
- return ablobStore;
+ return null;
}
I'm guessing this should disappear? But that's in the other pull request, from
what I recall...
---
Reply to this email
In general, looks good. Only a couple of minor questions, and comments about
formatting. Glad to see so much code hopefully go away soon!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/220#issuecomment-29693590
@@ -34,8 +34,14 @@
jclouds.test.listener /
jclouds.osgi.activatororg.jclouds.scriptbuilder.functionloader.osgi.Activator/jclouds.osgi.activator
-
jclouds.osgi.exportorg.jclouds.scriptbuilder*;version=${project.version}/jclouds.osgi.export
-
Hi all. The cloud compute provider I faced with (ProfitBricks) doesn't
have any predefined hardware profiles. Does it mean I need to have my
own /TemplateBuilder/ implementation since base /TemplateBuilderImpl/
will throw an exception if there is no hardware profiles to satisfy
user requirements?
Thanks for the cleanup, @shevchenator - looks good to me!
@nacx: whenever you're ready, I'd say squash'n'rebase and then good to merge..?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/41#issuecomment-29695355
Could you explain the background for this? Where previously jclouds could do
work for you (and work that it should seemingly be able to do, i.e. calculate
the MD5 for content you've already given it), we now expect you to do the work
yourself, and get the implementation right?
Is there any
+ authenticatedGET().endpoint(endpoint +
/routers).addQueryParam(fields, id, tenant_id, name).build(),
+
HttpResponse.builder().statusCode(200).payload(payloadFromResourceWithContentType(/list_routers.json,
APPLICATION_JSON)).build())
+
For repeatable payloads like InputSupplier it incurs IO twice and for
non-repeatable payloads like InputStream it
buffers the entire bolus in-memory, often times causing OutOfMemoryError
Rather than removing it, would it be feasible to simply fix/amend those
implementations to be less
jclouds-java-7-pull-requests #892 UNSTABLE
Unrelated [test
@@ -34,8 +34,14 @@
jclouds.test.listener /
jclouds.osgi.activatororg.jclouds.scriptbuilder.functionloader.osgi.Activator/jclouds.osgi.activator
-
jclouds.osgi.exportorg.jclouds.scriptbuilder*;version=${project.version}/jclouds.osgi.export
-
@@ -34,8 +34,14 @@
jclouds.test.listener /
jclouds.osgi.activatororg.jclouds.scriptbuilder.functionloader.osgi.Activator/jclouds.osgi.activator
-
jclouds.osgi.exportorg.jclouds.scriptbuilder*;version=${project.version}/jclouds.osgi.export
-
It should be properly working now (I have just run it on my openstack
instance).
Great to hear! Could you post the sample code you used to test this somewhere
(in a comment, Gist, Pastie etc.)?
Thanks, @sallum!
---
Reply to this email directly or view it on GitHub:
This is not just the test failing, but the equals method not being properly
implemented. Could you kindly fix that?
Good catch, @nacx!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/41#issuecomment-29961986
Does http://jclouds.apache.org/documentation/userguide/using-ec2/ also need to
be modified?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/221#issuecomment-30045097
Thanks for the updates, @eevans. Almost there, I think.
Would this functionality be exercised by any of the existing live tests? If so,
could you run those and add the results here? Just to ensure this works in
real life too ;-)
---
Reply to this email directly or view it on GitHub:
+import com.google.common.base.Charsets;
+import com.google.common.io.ByteStreams;
+
+@Test
+public class BasePayloadSlicerTest {
+
+ @Test
+ public void testIterableSliceExpectedSingle() throws IOException {
+ PayloadSlicer slicer = new BasePayloadSlicer();
+ String data =
exercises this new code, is that what you're looking for?
Almost...but these look like the _unit_ tests, not the [_live_
tests](http://jclouds.apache.org/documentation/devguides/provider-testing/)
(which are run against a real OpenStack instance).
Everett Toews and/or Zack Shoylev would be
Quoting ssiv...@gmail.com ssiv...@gmail.com:
Hi all!
Sorry guys, I'll duplicate my question posted on the #jclouds.
Is there an uniform way to add node firewall settings via compute
service? Or it's too specific for each provider so I need to you
provider API directly? I'm a little bit confused
Thanks for rewording, @abayer! +1 - looks good to me!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/221#issuecomment-30095021
@andrewgaul: would you have a chance to take a quick look at this, as one of
the BlobStore experts?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/220#issuecomment-30095087
There are 20 open PRs against jclouds/jclouds [1] at present. Quite a
few are over 3 months old. Would it be worth having a quick sweep
through especially the older ones and closing out any that do not seem
viable at present, or for 1.7.0?
Regards
ap
[1]
Thanks for the fix, @Kentzo and @shevchenator! Could you run the live tests and
post the results here, in a Gist or Pastie? Or would you have time to run the
live tests again, @nacx?
---
Reply to this email directly or view it on GitHub:
Just to complete Andrew's answer, there is also the SecurityGroupExtension
for the ComputeService.
Thanks for clarifying that, Ignasi! Learned something new again ;-)
Note that this extension is in beta and is only available on
1.7.0-SNAPSHOT [1].
ap
[1]
@iocanel: Any chance of adding a short comment in the POM to explain what you
explained in the review comments? Then hopefully we can get this in for 1.7.0?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/219#issuecomment-30169890
@andrewgaul: irrespective of whether it makes sense to try to fix the
implementation rather than remove it - I guess this would count as a breaking
change? Or do we feel this is used internally only, so we wouldn't be impacting
users here?
---
Reply to this email directly or view it on GitHub:
@andrewgaul: ping? Something to try to get in for 1.7.0?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/165#issuecomment-30170255
@Override
public String sign(String toSign) {
try {
- ByteProcessorbyte[] hmacSHA256 =
asByteProcessor(crypto.hmacSHA256(creds.get().credential.getBytes(UTF_8)));
- return base64().encode(readBytes(toInputStream(toSign),
hmacSHA256));
+
@@ -146,6 +146,7 @@ public PayloadBlobBuilder payload(Payload payload) {
return builder.payload(payload);
}
+ @Deprecated
See previous comment?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/223/files#r8213984
+1 too. It's been 6 months, but can we merge this one?
Quick JIRA issue merge? Will close'n'reopen now to re-trigger the PR builders.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/38#issuecomment-30186748
Still the same [clojure
failure](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/441/console)
by the way, it seems:
```
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
com.theoryinpractise:clojure-maven-plugin:1.3.10:test (test-clojure) on project
or is still some investigation pending regarding the test?
I still think `MediaType` should be non-nullable. Ideally, I'd like to try a
variant of this PR with a `checkNotNull` to see if that works too.
---
Reply to this email directly or view it on GitHub:
Committed to
[master](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=acde2beff1d04301af69a68ce598d7d3a96a92f0).
Any fixes we want to make to avoid potential OOMEs can be added in a separate
PR, I think.
---
Reply to this email directly or view it on GitHub:
@@ -121,6 +121,7 @@
*
* @see Payloads#calculateMD5
*/
+ @Deprecated
Use the [`@deprecated` Javadoc
tag](http://docs.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html#javadoc_tag)?
Renders more nicely in the Javadoc, then.
Happy to amend
I've added comments to all old PRs I've found. Let's see if we get
some feedback and can merge/close! :)
Thanks, Ignasi!
ap
jclouds-java-7-pull-requests #908 UNSTABLE
Weird
[failure](https://jclouds.ci.cloudbees.com/job/jclouds-java-7-pull-requests/org.apache.jclouds.common$azure-common/908/testReport/junit/org.jclouds.azure.storage.filters/SharedKeyLiteAuthenticationTest/testIdempotent/).
Not obviously related,
Alternative version of #44
You can merge this Pull Request by running:
git pull https://github.com/jclouds/jclouds pr-44-alternative
Or you can view, comment on it, or merge it online at:
https://github.com/jclouds/jclouds/pull/225
-- Commit Summary --
* Allowing Guava MediaType for
Let's see what the PR builders say!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/225#issuecomment-30190231
jclouds-pull-requests #446 UNSTABLE
Egads! Not **again**. [This
one](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/org.apache.jclouds$jclouds-compute/446/testReport/junit/org.jclouds.compute.util/ConcurrentOpenSocketFinderTest/testChecksSocketsConcurrently/)
also looks weird,
jclouds-pull-requests #447 FAILURE
They say: sucks boo, it seems ;-) Clojure fix coming up...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/225#issuecomment-30195108
Yay. Finally! Only JIRA, rebase'n'merge to go now...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/38#issuecomment-30195194
Thanks for the explanations, @eevans! Perhaps add a comment in the test to
explain why `InputStream` is used rather than `File`? Otherwise, fine to leave
as-is.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/192#issuecomment-30200199
The Clojure ugliness looks pretty significant, at least to me. And if one
variant of `contentType` is nullable, why not the other one, I guess.
Closing this one out - let's stick with #44...
---
Reply to this email directly or view it on GitHub:
@nacx: _I_ certainly think so! Was waiting for someone else to have a look and
+1...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs-openstack/pull/53#issuecomment-30201486
@andrewgaul: one small comment left about potentially marking the `contentType`
args as `@Nullable`? Otherwise, JIRA issue is
[JCLOUDS-402](https://issues.apache.org/jira/browse/JCLOUDS-402).
---
Reply to this email directly or view it on GitHub:
@@ -107,6 +108,8 @@
PayloadBlobBuilder contentMD5(byte[] md5);
+ PayloadBlobBuilder contentType(MediaType contentType);
Mark `MediaType` (and the `String` version below, actually) as `@Nullable`?
---
Reply to this email directly or view it on GitHub:
Can this be merged?
I think we first need to address a bunch of new [Checkstyle
violations](https://jclouds.ci.cloudbees.com/job/jclouds-karaf-pull-requests/18/org.apache.jclouds.karaf$cache/violations/)?
---
Reply to this email directly or view it on GitHub:
MultimapString, Object queryParams = addQueryParams(tokenValues,
invocation);
- MultimapString, String headers = buildHeaders(tokenValues,
invocation);
+
+ MultimapString, String headers;
+
+ if (caller != null) {
+ headers = buildHeaders(tokenValues,
Hmmm, isn't this the good old use install goal issue?
Let's find out! Just changed the job config...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/24#issuecomment-30232378
@@ -128,6 +132,31 @@ public void testMultipartChunkedFileStream() throws
IOException, InterruptedExce
}
}
+ @Test(groups = { integration, live })
+ public void testMultipartChunkedInputStream() throws
InterruptedException, IOException {
+ String container =
MultimapString, Object queryParams = addQueryParams(tokenValues,
invocation);
- MultimapString, String headers = buildHeaders(tokenValues,
invocation);
+
+ MultimapString, String headers;
+
+ if (caller != null) {
+ headers = buildHeaders(tokenValues,
Just to be sure this is not unnoticed, this change will also propagate the
@Produces and @Consumes annotations
I guess the only place we might need to worry about this is where a call
currently assumes default produces/consumes (i.e. doesn't set anything
explicitly), but might now be
Agree, but as long as we are including them in the header propagation
logic, we should add the tests to make
sure that (even if rarely used) the code actually works as expected for them
too.
Indeed. Do we also have tests on the _callee_ side to verify expected header
params which would
Are we sure this has been configured?
I haven't been able to change BuildHive yet, but here's the screenshot from the
DEV@cloud config:
And I can see a bunch of install invocations in the
PS: Perhaps the Maven setup is wrong, and we need to run `install` on the
**whole** project, with tests disabled, before running the tests again?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/24#issuecomment-30248229
Let's quickly try again with this new setup...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-karaf/pull/24#issuecomment-30248561
Personally (no offense) I wouldn't like to merge this without a complete test
set.
No offence taken ;-) I certainly agree we should have tests to ensure the
change works as intended.
I was just wondering whether we have tests that would be able to verify that
the new behaviour doesn't
Looks good to me - only squash'n'rebase to go, from my perspective.
@andrewgaul: you OK with investigating ByteStreams as a follow-up improvement,
or would you like to see that tackled first?
---
Reply to this email directly or view it on GitHub:
jclouds ยป jclouds-karaf #615 SUCCESS
This is unfortunately wrong :-( The tests actually
[failed](https://buildhive.cloudbees.com/job/jclouds/job/jclouds-karaf/615/console)
```
Tests run: 57, Failures: 55, Errors: 0, Skipped: 2
[ERROR] There are test failures.
```
---
Reply to this email
You can merge this Pull Request by running:
git pull https://github.com/jclouds/jclouds-site release-notes-1.6.3
Or you can view, comment on it, or merge it online at:
https://github.com/jclouds/jclouds-site/pull/35
-- Commit Summary --
* WIP for the 1.6.3 release notes
-- File
Quick update...
Javadocs available and permalinks updated:
http://demobox.github.com/jclouds-maven-site/latest/
http://demobox.github.com/jclouds-maven-site/1.6.x/
(Incomplete) PR to update site release notes open too [1]. @gaul: I
guess you'll want to amend that one - it's a branch in the
or is that left to whomever does the merge?
If you could do that and force push this PR branch, it would be appreciated.
Reason being: we then get the PR build jobs to run over this once more.
Thanks!
---
Reply to this email directly or view it on GitHub:
Looks good to me, too. @nacx: good to go on this one?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/226#issuecomment-30303663
haven't tried on a clean repo.
It does indeed look like a problem with _this_ PR :-( The
[jobs](https://jclouds.ci.cloudbees.com/job/jclouds-karaf-pull-requests/lastBuild/testReport/)
[for](https://buildhive.cloudbees.com/job/jclouds/job/jclouds-karaf/616/testReport/)
#28 seem to be almost
jclouds-karaf-pull-requests #22 UNSTABLE
No failures but [two tests
skipped](https://jclouds.ci.cloudbees.com/job/jclouds-karaf-pull-requests/org.apache.jclouds.karaf$itests/22/testReport/),
for some reason..?
---
Reply to this email directly or view it on GitHub:
jclouds-karaf-pull-requests #22 UNSTABLE
Ah...the skipped tests are intended (also skipped in BuildHive). It's
_Checkstyle_ that's causing the build to go unstable in DEV@cloud.
---
Reply to this email directly or view it on GitHub:
One small comment, but otherwise looks good to me - thanks, @zack-shoylev!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-examples/pull/24#issuecomment-30312466
Committed to
[master](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=c40dc996d96b05ce755f28728a4fb2bcd632b247).
Thanks, @everett-toews and @nacx!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/226#issuecomment-30316146
@zack-shoylev: this is merged but not deployed yet? Can't seem to find
autoscale anywhere on [the rendered
page](http://jclouds.apache.org/documentation/quickstart/rackspace/)?
---
Reply to this email directly or view it on GitHub:
+ */
+ assertNotNull(g);
+ assertEquals(g.getId(),6791761b-821a-4d07-820d-0b2afc7dd7f6);
+ assertEquals(g.getLinks().size(), 1);
+ assertEquals(g.getLinks().get(0).getHref().toString(),
+ assertRequest(server.takeRequest(), GET, /v1.0/88/groups);
+
+ /*
+ * Check response
+ */
+ assertEquals(groupStates.size(),2);
+
+ assertEquals(groupStates.get(0).getGroupInstances().size(), 0);
+
+ .maxEntities(100)
+ .metadata(ImmutableMap.of(firstkey, this is a string,
secondkey, 1))
+ .build();
+
+ boolean result = api.updateGroupConfiguration(1234567890, gc);
+
+ /*
+ * Check request
+ */
+
@@ -128,6 +132,31 @@ public void testMultipartChunkedFileStream() throws
IOException, InterruptedExce
}
}
+ @Test(groups = { integration, live })
+ public void testMultipartChunkedInputStream() throws
InterruptedException, IOException {
+ String container =
Thanks, @eevans! Did we lose a comment somewhere in the tests about using an
`InputStream` vs. a `File`?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/192#issuecomment-30327046
Nope, it's right here
Doh! Some change blindness on my side there...thanks.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/192#issuecomment-30328796
Committed to
[master](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=15a3c04).
Thanks, @eevans!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/192#issuecomment-30330191
jclouds-pull-requests #463 FAILURE
jclouds-java-7-pull-requests #925 FAILURE
Infra failure, nothing wrong with the PR, I think:
```
Looks like the node went offline during the build.
```
---
Reply to this email directly or view it on GitHub:
+
assertEquals(g.getLaunchConfiguration().getPersonalities().get(0).getContents(),
VGhpcyBpcyBhIHRlc3QgZmlsZS4=);
+ assertEquals(g.getLaunchConfiguration().getNetworks().size(), 2);
+ assertEquals(g.getLaunchConfiguration().getNetworks().get(0),
I am not sure what the process is for deploying. Is it automatic?
No, not as far as I know...see [the
README](https://github.com/jclouds/jclouds-site/blob/master/README.md)
---
Reply to this email directly or view it on GitHub:
*/
public class BaseOpenStackMockTestA extends Closeable {
- public static final String accessRackspace =
@@ -72,6 +73,14 @@ public BindSwiftObjectMetadataToRequest(ObjectToBlob
object2Blob, BindUserMetada
.build();
}
+ Date expires = object.getPayload().getContentMetadata().getExpires();
+ if (expires != null) {
+ // Swizzle Expires to X-Delete-At
@@ -67,6 +70,7 @@ public void testExtendedPropertiesBind() {
BindSwiftObjectMetadataToRequest binder =
injector.getInstance(BindSwiftObjectMetadataToRequest.class);
assertEquals(binder.bindToRequest(request, object),
HttpRequest.builder().method(PUT)
+
JIRA issue for this? And will close'n'reopen to see what the PR builders say
this time...
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/227#issuecomment-30343973
Thanks, @zack-shoylev! Numbering's gone a bit weird again..?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/32#issuecomment-30365345
Also, one of the links seems broken:
results in a 404
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-site/pull/32#issuecomment-30365796
Couple more points:
looks like the wrong package? And here:
I'm guessing that should be
+1 - looks good to me. Thanks, @andrewgaul!
Has this been run against any live cloud so far, by the way?
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/227#issuecomment-30367992
*/
public class BaseOpenStackMockTestA extends Closeable {
- public static final String accessRackspace =
-1 - doesn't look good to me :-( All the lists are squashed now: compare
with the old version
201 - 300 of 1315 matches
Mail list logo
