I've verified the aws-ec2 provider with the compute-basics tool from jclouds-example and successfully created nodes, run scripts, listed images and deleted them.
I've Also verified the jclouds CLI and the persistent compute services from the interactive karaf version. And here are the results of the live tests I've run: chef: Tests run: 66, Failures: 0, Errors: 0, Skipped: 0 (Total time: 2:15 m) azurecompute-arm: Tests run: 151, Failures: 1, Errors: 0, Skipped: 2 (Total time: 02:58 h) digitalocean2: Tests run: 67, Failures: 1, Errors: 0, Skipped: 10 (Total time: 20:50 m) packet: Tests run: 53, Failures: 0, Errors: 0, Skipped: 0 (Total time: 01:02 h) The digitalocean2 failures are the same ones spotted in the previous release. A misconfiguration in the test picks a wrong hardware profile and the creation of the initial droplet fails, making all subsequent tests in the class to be skipped. The API works, though, as all compute service tests succeed, so it is only a matter of a wrong test setup. In Azure there is one single failure to investigate related tot he metrics API, nothing to consider blocker. The skipped tests are expected as they are about configurations not supported by the Azure ARM security group extension. == Stacktraces == azurecompute-arm: listVirtualMachineMetrics(org.jclouds.azurecompute.arm.features.MetricsApiLiveTest) Time elapsed: 43.624 sec <<< FAILURE! java.lang.AssertionError: expected [1] but found [0] at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:494) at org.testng.Assert.assertEquals(Assert.java:123) at org.testng.Assert.assertEquals(Assert.java:370) at org.testng.Assert.assertEquals(Assert.java:380) at org.jclouds.azurecompute.arm.features.MetricsApiLiveTest.listVirtualMachineMetrics(MetricsApiLiveTest.java:130) digitalocean2: testCreate(org.jclouds.digitalocean2.features.DropletApiLiveTest) Time elapsed: 0.985 sec <<< FAILURE! org.jclouds.http.HttpResponseException: command: POST https://api.digitalocean.com/v2/droplets HTTP/1.1 failed with response: HTTP/1.1 422 Unprocessable Entity; content: [{"id":"unprocessable_entity","message":"Cannot create a droplet with a smaller disk (20GB) than the image (30GB)."}] at org.jclouds.digitalocean2.handlers.DigitalOcean2ErrorHandler.handleError(DigitalOcean2ErrorHandler.java:43) at org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:65) at org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:140) at org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:109) at org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90) at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73) at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44) at org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117) at com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87) at com.sun.proxy.$Proxy79.create(Unknown Source) at org.jclouds.digitalocean2.features.DropletApiLiveTest.testCreate(DropletApiLiveTest.java:75) On 27 November 2017 at 14:20, Ignasi Barrera <n...@apache.org> wrote: > Andrew, regarding the test, I'd say an input string for each OS would make > sense. @gaul, WDYT? > Regarding the release, if this is just about the test configuration but > not the behavior of the filesystem API itself, I'd say we should not block > the release for this reason? > > @andrea, thanks for running it on Java 7. May you post your vote by > replying to the [VOTE] thread? It is a PITA that Gmail collapses both > threads as one. One way to see the threads properly is to temporarily go to > the Gmail settings, and turn the conversation view off. > Regarding the failure in Java 8, I think it is some configuration in the > vagrant-java-bindings library we use. Perhaps @neykov can help here? > > *Caused by: org.osgi.framework.BundleException: Unresolved constraint in > bundle name.neykov.vagrant-java-bindings [87]: Unable to resolve 87.0: > missing requirement [87.0] osgi.ee <http://osgi.ee>; (&(osgi.ee > <http://osgi.ee>=JavaSE)(version=1.6))* > > > On 26 November 2017 at 21:35, Andrea Turli <andrea.tu...@gmail.com> wrote: > >> hi, >> >> I've just rebuilt with java 7 >> >> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; >> 2017-10-18T07:58:13Z) >> Maven home: /usr/share/maven >> Java version: 1.7.0_151, vendor: Oracle Corporation >> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre >> Default locale: en, platform encoding: UTF-8 >> OS name: "linux", version: "4.9.44-linuxkit-aufs", arch: "amd64", family: >> "unix" >> >> and jclouds-karaf has no issues >> >> [INFO] Reactor Summary: >> [INFO] >> [INFO] Apache jclouds :: Karaf ............................ SUCCESS [ >> 46.836 s] >> [INFO] jclouds :: Karaf :: Core ........................... SUCCESS [ >> 5.985 s] >> [INFO] jclouds :: Karaf :: Bundles ........................ SUCCESS [ >> 0.172 s] >> [INFO] jclouds :: Karaf :: JSch Agentproxy for JSch (shaded bundle) >> SUCCESS >> [ 5.848 s] >> [INFO] jclouds :: Karaf :: Utils .......................... SUCCESS [ >> 2.720 s] >> [INFO] jclouds :: Karaf :: Recipe ......................... SUCCESS [ >> 2.926 s] >> [INFO] jclouds :: Karaf :: Cache .......................... SUCCESS [ >> 3.302 s] >> [INFO] jclouds :: Karaf :: Services ....................... SUCCESS [ >> 7.548 s] >> [INFO] jclouds :: Karaf :: Commands ....................... SUCCESS [ >> 13.752 s] >> [INFO] jclouds :: Karaf :: URL Handler .................... SUCCESS [ >> 2.393 s] >> [INFO] jclouds :: Karaf :: Chef ........................... SUCCESS [ >> 0.370 s] >> [INFO] jclouds :: Karaf :: Chef :: Core ................... SUCCESS [ >> 1.955 s] >> [INFO] jclouds :: Karaf :: Chef :: Services ............... SUCCESS [ >> 4.195 s] >> [INFO] jclouds :: Karaf :: Chef :: Commands ............... SUCCESS [ >> 8.073 s] >> [INFO] jclouds :: Karaf :: Chef :: Cache .................. SUCCESS [ >> 2.842 s] >> [INFO] jclouds :: Karaf :: Feature ........................ SUCCESS [ >> 7.439 s] >> [INFO] jclouds :: Karaf :: Integration Tests .............. SUCCESS [17:05 >> min] >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD SUCCESS >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Total time: 19:04 min >> [INFO] Finished at: 2017-11-26T20:28:31Z >> [INFO] Final Memory: 42M/280M >> [INFO] >> ------------------------------------------------------------------------ >> >> >> I change my vote to +1 >> >> On Sun, Nov 26, 2017 at 9:20 PM, Andrew Phillips <aphill...@qrmedia.com> >> wrote: >> >> > Please use this thread for discussion of issues uncovered in the RC, >> >> questions you may have about the RC, etc. >> >> >> > >> > The following test fails repeatedly for me on Windows: >> > >> > Failed tests: >> > FilesystemStorageStrategyImplTest.testDeletingInvalidPathFil >> > eEndsNormally:695 >> > Deleting an invalid path ended with an InvalidPathException. >> > >> > Specifically, it's the "/" character in the test input "A<!:!@#$%^&*?]8 >> > /\0"; removing that works. >> > >> > Would having an OS-specific test input seem like the correct solution? >> Or >> > should the test be modified to expect a test failure on Windows? >> > >> > Regards >> > >> > ap >> > >> > >
