brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sjcorbett <...@git.apache.org>
Subject [GitHub] brooklyn-server pull request #651: Test speedups
Date Fri, 05 May 2017 15:24:05 GMT
Github user sjcorbett commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/651#discussion_r115023121
  
    --- Diff: locations/jclouds/src/test/java/org/apache/brooklyn/location/jclouds/DefaultConnectivityResolverTest.java
---
    @@ -147,10 +149,9 @@ public void testResolveChecksCredentials() throws Exception {
             ConfigBag config = ConfigBag.newInstance(ImmutableMap.of(
                     JcloudsLocationConfig.LOOKUP_AWS_HOSTNAME, false,
                     JcloudsLocationConfig.WAIT_FOR_SSHABLE, "1ms",
    +                JcloudsLocationConfig.POLL_FOR_FIRST_REACHABLE_ADDRESS, "1ms",
                     JcloudsLocation.CUSTOM_CREDENTIALS, credential));
    -        ConnectivityResolverOptions options = newResolveOptions()
    -                .pollForReachableAddresses(Predicates.in(reachableIps), Duration.ONE_SECOND,
true)
    --- End diff --
    
    No, and they don't. The timeout is used in a handful of places. In the case of the failure
above I reckon the flow was:
    
    * `DefaultConnectivityResolver` favours address and credential pairs that can be used
for SSH/WinRM.†
    * It tests connectivity with `JcloudsLocation.waitForReachable` via `waitForSshable`.
    * `waitForReachable` uses a `Repeater` whose timeout is configured by this test to 1ms.
    * The Repeater calls `future.get(1ms)`. The task does not complete in time on slow Jenkins
so a `TimeoutException` is thrown. (For reference, the Repeater's task uses `RecordingSshTool`
which uses the response generator defined in the test case.)
    * DefaultConnectivityResolver falls back to the first available address.
    * The test fails.
    
    I see https://github.com/apache/brooklyn-server/commit/f9cb0b2447b02d93fe2b39496320cb1c920be3ff
changed Repeater to respect timeouts and imagine the tighter constraints have forced the failure.
Before that commit the repeater would have waited the full initial delay, which in this case
is configured by `waitForReachable` to be one second.
    
    † e.g. if jclouds gives it `addresses=[10.0.0.1, 10.0.0.2]` and `credentials=[key1,
key2]` and the instance is only accessible on `key2@10.0.0.2` it will do its best to find
that out. It checks addresses in order so in this example would have tested and rejected the
other three combinations of address and key.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message