Just FTR, the DigitalOcean tests will be fixed in the next release: https://github.com/jclouds/jclouds/pull/1161
On 27 November 2017 at 20:28, Ignasi Barrera <n...@apache.org> wrote: > 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 >>> > >>> >> >> >
