Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.6.0
    • Fix Version/s: 0.6.0
    • Component/s: core
    • Labels:
      None

      Description

      There are a few problems in our maven configuration, and a couple places where we aren't using the best jclouds configuration.

      • in our pom files, we needlessly declare transitive dependencies modules. this is unnecessary maintenance, as jclouds version/dependency configuration is scoped to whirr core
      • we've switched to SLF4J, yet haven't configured jclouds to use it
      • especially considering we are uploading large blobs, we should be using the jclouds EnterpriseConfigurationModule which handles file slicing much more effectively.
      1. WHIRR-361.patch
        5 kB
        Adrian Cole
      2. WHIRR-361.patch
        5 kB
        Adrian Cole
      3. WHIRR-361.patch
        15 kB
        Adrian Cole
      4. WHIRR-361.patch
        5 kB
        Andrei Savu
      5. ConfigureClusterAction.java
        6 kB
        Adrian Cole
      6. WHIRR-361-fixguava.patch
        1.0 kB
        Adrian Cole
      7. org.apache.whirr.service.hbase.integration.HBase089ServiceTest.txt
        2.06 MB
        Andrei Savu
      8. WHIRR-361.patch
        13 kB
        Adrian Cole

        Issue Links

          Activity

          Hide
          Adrian Cole added a comment -

          tested successfully BlobCacheTest with the following java args: -Dwhirr.test.provider=aws-ec2 -Dwhirr.test.identity=XXXX -Dwhirr.test.credential=XXX

          2011-08-13 10:53:45,908 INFO [org.apache.whirr.util.BlobCache] (main) Created blob cache container '5x7h63enpifg' located in 'null'
          2011-08-13 10:53:46,630 INFO [org.apache.whirr.util.BlobCache] (main) Uploading 'whirr5985646567714705282.txt' to '5x7h63enpifg' blob cache.
          2011-08-13 10:53:52,873 INFO [org.apache.whirr.util.integration.BlobCacheTest] (main) (mkdir -p /tmp && cd /tmp && [ ! -f whirr5985646567714705282.txt ] && curl -C - -s -q -L --connect-timeout 10 --max-time 600 -X GET -s --retry 20 -H "Host: 5x7h63enpifg.s3.amazonaws.com" -H "Date: Sat, 13 Aug 2011 09:53:28 GMT" -H "Authorization: AWS 067PW7Z9P0FNH7JDPE82:eMRoiIqAe9u4I0/oh5uuzu7hApM=" https://5x7h63enpifg.s3.amazonaws.com/whirr5985646567714705282.txt >whirr5985646567714705282.txt)

          2011-08-13 10:53:52,873 INFO [org.apache.whirr.util.BlobCache] (main) Removing blob cache '5x7h63enpifg'
          2011-08-13 10:53:57,036 INFO [org.apache.whirr.util.BlobCache] (main) Created blob cache container 'ym26jg2ijmgz' located in 'null'
          2011-08-13 10:53:57,394 INFO [org.apache.whirr.util.BlobCache] (main) Uploading 'whirr4809328296500028829.txt' to 'ym26jg2ijmgz' blob cache.
          2011-08-13 10:55:56,399 INFO [org.apache.whirr.util.integration.BlobCacheTest] (main) (mkdir -p /tmp && cd /tmp && [ ! -f whirr4809328296500028829.txt ] && curl -C - -s -q -L --connect-timeout 10 --max-time 600 -X GET -s --retry 20 -H "Host: ym26jg2ijmgz.s3.amazonaws.com" -H "Date: Sat, 13 Aug 2011 09:55:45 GMT" -H "Authorization: AWS 067PW7Z9P0FNH7JDPE82:X1GLlfJtG6O+WHNFsoAN9yHg+7A=" https://ym26jg2ijmgz.s3.amazonaws.com/whirr4809328296500028829.txt >whirr4809328296500028829.txt)

          2011-08-13 10:55:56,399 INFO [org.apache.whirr.util.BlobCache] (main) Removing blob cache 'ym26jg2ijmgz'
          2011-08-13 10:56:18,436 INFO [org.apache.whirr.util.integration.BlobCacheTest] (main) Created temporary container 'ucnzfrosudrx'
          2011-08-13 10:56:19,256 INFO [org.apache.whirr.util.integration.BlobCacheTest] (main) Removing temporary container 'ucnzfrosudrx'

          Show
          Adrian Cole added a comment - tested successfully BlobCacheTest with the following java args: -Dwhirr.test.provider=aws-ec2 -Dwhirr.test.identity=XXXX -Dwhirr.test.credential=XXX 2011-08-13 10:53:45,908 INFO [org.apache.whirr.util.BlobCache] (main) Created blob cache container '5x7h63enpifg' located in 'null' 2011-08-13 10:53:46,630 INFO [org.apache.whirr.util.BlobCache] (main) Uploading 'whirr5985646567714705282.txt' to '5x7h63enpifg' blob cache. 2011-08-13 10:53:52,873 INFO [org.apache.whirr.util.integration.BlobCacheTest] (main) (mkdir -p /tmp && cd /tmp && [ ! -f whirr5985646567714705282.txt ] && curl -C - -s -q -L --connect-timeout 10 --max-time 600 -X GET -s --retry 20 -H "Host: 5x7h63enpifg.s3.amazonaws.com" -H "Date: Sat, 13 Aug 2011 09:53:28 GMT" -H "Authorization: AWS 067PW7Z9P0FNH7JDPE82:eMRoiIqAe9u4I0/oh5uuzu7hApM=" https://5x7h63enpifg.s3.amazonaws.com/whirr5985646567714705282.txt >whirr5985646567714705282.txt) 2011-08-13 10:53:52,873 INFO [org.apache.whirr.util.BlobCache] (main) Removing blob cache '5x7h63enpifg' 2011-08-13 10:53:57,036 INFO [org.apache.whirr.util.BlobCache] (main) Created blob cache container 'ym26jg2ijmgz' located in 'null' 2011-08-13 10:53:57,394 INFO [org.apache.whirr.util.BlobCache] (main) Uploading 'whirr4809328296500028829.txt' to 'ym26jg2ijmgz' blob cache. 2011-08-13 10:55:56,399 INFO [org.apache.whirr.util.integration.BlobCacheTest] (main) (mkdir -p /tmp && cd /tmp && [ ! -f whirr4809328296500028829.txt ] && curl -C - -s -q -L --connect-timeout 10 --max-time 600 -X GET -s --retry 20 -H "Host: ym26jg2ijmgz.s3.amazonaws.com" -H "Date: Sat, 13 Aug 2011 09:55:45 GMT" -H "Authorization: AWS 067PW7Z9P0FNH7JDPE82:X1GLlfJtG6O+WHNFsoAN9yHg+7A=" https://ym26jg2ijmgz.s3.amazonaws.com/whirr4809328296500028829.txt >whirr4809328296500028829.txt) 2011-08-13 10:55:56,399 INFO [org.apache.whirr.util.BlobCache] (main) Removing blob cache 'ym26jg2ijmgz' 2011-08-13 10:56:18,436 INFO [org.apache.whirr.util.integration.BlobCacheTest] (main) Created temporary container 'ucnzfrosudrx' 2011-08-13 10:56:19,256 INFO [org.apache.whirr.util.integration.BlobCacheTest] (main) Removing temporary container 'ucnzfrosudrx'
          Hide
          Andrei Savu added a comment -

          I've just committed this. Nice cleanup!

          Show
          Andrei Savu added a comment - I've just committed this. Nice cleanup!
          Hide
          Andrei Savu added a comment -

          I'm reopening this issue because on the current trunk I'm unable to run the HBase & CDH integration tests. I'm seeing a long list of Google Guice ProvisionException's (probably a classpath issue).

          Show
          Andrei Savu added a comment - I'm reopening this issue because on the current trunk I'm unable to run the HBase & CDH integration tests. I'm seeing a long list of Google Guice ProvisionException's (probably a classpath issue).
          Hide
          Tom White added a comment -

          Are you able to run Hadoop and ZK integration tests? They are failing for me since the nodes are unable to connect to each other on the private addresses. Not sure what caused that.

          Show
          Tom White added a comment - Are you able to run Hadoop and ZK integration tests? They are failing for me since the nodes are unable to connect to each other on the private addresses. Not sure what caused that.
          Hide
          Andrei Savu added a comment -

          Hadoop works for me on cloudservers & ec2 with the current trunk. Actually everything seems to be working fine and predictable on Rackspace. On EC2 I'm seeing a lot of strange failures and I'm starting to think this is somehow related to the automatically selected image. I'm planning to do more testing against a vanilla Ubuntu 10.04 LTS server but first we should fix the pom files so that we no longer get Guice exceptions in jclouds.

          Show
          Andrei Savu added a comment - Hadoop works for me on cloudservers & ec2 with the current trunk. Actually everything seems to be working fine and predictable on Rackspace. On EC2 I'm seeing a lot of strange failures and I'm starting to think this is somehow related to the automatically selected image. I'm planning to do more testing against a vanilla Ubuntu 10.04 LTS server but first we should fix the pom files so that we no longer get Guice exceptions in jclouds.
          Hide
          Adrian Cole added a comment -

          guys, would be easier to troubleshoot if we paste/attach stack traces and note the specific test cases or otherwise that fail w/parameters

          Show
          Adrian Cole added a comment - guys, would be easier to troubleshoot if we paste/attach stack traces and note the specific test cases or otherwise that fail w/parameters
          Hide
          Andrei Savu added a comment -

          This is the error log I get when trying to run the HBase integration tests. It's the same with maven2 & 3.

          Show
          Andrei Savu added a comment - This is the error log I get when trying to run the HBase integration tests. It's the same with maven2 & 3.
          Hide
          Adrian Cole added a comment -

          HBase errors are related to a classpath conflict.

          com.google.common.collect.ImmutableSet.copyOf(Ljava/util/Collection is in Guava, but not google-collections which it replaced some time back.

          funny quote from google-collections homepage: "What you see here is ancient and unmaintained. Do not use it."

          I'll hunt down the jar that has this in it.

          Show
          Adrian Cole added a comment - HBase errors are related to a classpath conflict. com.google.common.collect.ImmutableSet.copyOf(Ljava/util/Collection is in Guava, but not google-collections which it replaced some time back. funny quote from google-collections homepage: "What you see here is ancient and unmaintained. Do not use it." I'll hunt down the jar that has this in it.
          Hide
          Adrian Cole added a comment -

          ahh this isn't about google collections, rather an old version of guava. something is designating guava-r05, as the following is in the mvn dependency:tree output

          [INFO] org.apache.whirr:whirr-hbase:jar:0.6.0-incubating-SNAPSHOT
          [INFO] +- org.apache.whirr:whirr-core:jar:0.6.0-incubating-SNAPSHOT:compile
          [INFO] | +- ca.juliusdavies:not-yet-commons-ssl:jar:0.3.11:compile
          [INFO] | +- org.jclouds:jclouds-compute:jar:1.1.0:compile
          [INFO] | | +- org.jclouds:jclouds-scriptbuilder:jar:1.1.0:compile
          [INFO] | | - org.jclouds:jclouds-core:jar:1.1.0:compile
          [INFO] | | +- net.oauth.core:oauth:jar:20100527:compile
          [INFO] | | +- aopalliance:aopalliance:jar:1.0:compile
          [INFO] | | +- com.sun.jersey:jersey-core:jar:1.1.5.1:compile
          [INFO] | | +- com.google.inject.extensions:guice-assistedinject:jar:3.0:compile
          [INFO] | | +- com.google.inject:guice:jar:3.0:compile
          [INFO] | | +- javax.inject:javax.inject:jar:1:compile
          [INFO] | | +- javax.annotation:jsr250-api:jar:1.0:compile
          [INFO] | | +- com.google.code.gson:gson:jar:1.7.1:compile
          [INFO] | | +- com.google.guava:guava:jar:r05:compile
          -snip-

          Show
          Adrian Cole added a comment - ahh this isn't about google collections, rather an old version of guava. something is designating guava-r05, as the following is in the mvn dependency:tree output [INFO] org.apache.whirr:whirr-hbase:jar:0.6.0-incubating-SNAPSHOT [INFO] +- org.apache.whirr:whirr-core:jar:0.6.0-incubating-SNAPSHOT:compile [INFO] | +- ca.juliusdavies:not-yet-commons-ssl:jar:0.3.11:compile [INFO] | +- org.jclouds:jclouds-compute:jar:1.1.0:compile [INFO] | | +- org.jclouds:jclouds-scriptbuilder:jar:1.1.0:compile [INFO] | | - org.jclouds:jclouds-core:jar:1.1.0:compile [INFO] | | +- net.oauth.core:oauth:jar:20100527:compile [INFO] | | +- aopalliance:aopalliance:jar:1.0:compile [INFO] | | +- com.sun.jersey:jersey-core:jar:1.1.5.1:compile [INFO] | | +- com.google.inject.extensions:guice-assistedinject:jar:3.0:compile [INFO] | | +- com.google.inject:guice:jar:3.0:compile [INFO] | | +- javax.inject:javax.inject:jar:1:compile [INFO] | | +- javax.annotation:jsr250-api:jar:1.0:compile [INFO] | | +- com.google.code.gson:gson:jar:1.7.1:compile [INFO] | | +- com.google.guava:guava:jar:r05:compile - snip -
          Hide
          Adrian Cole added a comment -

          whirr uses guava directly and also indirectly. since we use it directly, we should put it as a dependency in compile scope with a version that doesn't conflict with our dependencies. currently, r09 is best. if we explicitly call this out, then changing unrelated dependencies won't cause weird issues like this.

          Show
          Adrian Cole added a comment - whirr uses guava directly and also indirectly. since we use it directly, we should put it as a dependency in compile scope with a version that doesn't conflict with our dependencies. currently, r09 is best. if we explicitly call this out, then changing unrelated dependencies won't cause weird issues like this.
          Hide
          Andrei Savu added a comment -

          I can confirm this fixes the classpath problem. I've just committed the patch. HBase integration tests are now running and passing on cloudservers-us.

          Show
          Andrei Savu added a comment - I can confirm this fixes the classpath problem. I've just committed the patch. HBase integration tests are now running and passing on cloudservers-us.
          Hide
          Andrei Savu added a comment -

          The same is true for CDH. All integration tests pass on Rackspace.

          Show
          Andrei Savu added a comment - The same is true for CDH. All integration tests pass on Rackspace.
          Hide
          Adrian Cole added a comment -

          testing zookeeper via mvn -Pintegration clean install -DargLine="-Dwhirr.test.provider=cloudservers-us ... works fine

          testing with -Dwhirr.test.provider=aws-ec2 and patch for WHIRR-341 which uses ami-63be790a has the following behavior:

          • Both nodes start and install zookeeper. However, it appears only one node seems to have scripts run on ConfigureClusterAction.doAction, so only one starts zookeeper in this case. This is visible in target/test-data/jclouds-compute.log and whirr.log

          This is completely repeatable, but I haven't isolated why this is occurring

          Show
          Adrian Cole added a comment - testing zookeeper via mvn -Pintegration clean install -DargLine="-Dwhirr.test.provider=cloudservers-us ... works fine testing with -Dwhirr.test.provider=aws-ec2 and patch for WHIRR-341 which uses ami-63be790a has the following behavior: Both nodes start and install zookeeper. However, it appears only one node seems to have scripts run on ConfigureClusterAction.doAction, so only one starts zookeeper in this case. This is visible in target/test-data/jclouds-compute.log and whirr.log This is completely repeatable, but I haven't isolated why this is occurring
          Hide
          Adrian Cole added a comment -

          much more useful logging, although I cannot find a way to get checkstyle to tell me what is wrong with the formatting

          Show
          Adrian Cole added a comment - much more useful logging, although I cannot find a way to get checkstyle to tell me what is wrong with the formatting
          Hide
          Adrian Cole added a comment -

          Please figure out a way to get the attached ConfigureClusterAction passing checkstyle, as it took a while to refine, but maven isn't telling me what is wrong with it.

          ok. logic is failing at the following redundant check:

          // Check it's the correct cluster
          if (!clusterSpec.getClusterName().equals(nodeMetadata.getGroup()))

          { return false; }

          we are already know it is in the cluster from the latter check on id (taken from cluster map), so the above code is redundant.

          For some reason in aws-ec2, the security group name isn't parsing properly which is why that check is failing. I'd recommend applying the attached version of ConfigureClusterAction, taking out the redundant cluster name check so that aws-ec2 can work without a patch on jclouds.

          I've verified the solution I'm recommending works, but please do re-check. Also note, I am using the patch in WHIRR-341 so that I'm testing against a stable ubuntu ami.

          Show
          Adrian Cole added a comment - Please figure out a way to get the attached ConfigureClusterAction passing checkstyle, as it took a while to refine, but maven isn't telling me what is wrong with it. ok. logic is failing at the following redundant check: // Check it's the correct cluster if (!clusterSpec.getClusterName().equals(nodeMetadata.getGroup())) { return false; } we are already know it is in the cluster from the latter check on id (taken from cluster map), so the above code is redundant. For some reason in aws-ec2, the security group name isn't parsing properly which is why that check is failing. I'd recommend applying the attached version of ConfigureClusterAction, taking out the redundant cluster name check so that aws-ec2 can work without a patch on jclouds. I've verified the solution I'm recommending works, but please do re-check. Also note, I am using the patch in WHIRR-341 so that I'm testing against a stable ubuntu ami.
          Hide
          Tom White added a comment -

          The checkstyle problem is reported in core/target/checkstyle-result.xml. It's complaining about the format of "nodeId" - it should be "NODE_ID".

          Running tests now.

          Show
          Tom White added a comment - The checkstyle problem is reported in core/target/checkstyle-result.xml. It's complaining about the format of "nodeId" - it should be "NODE_ID". Running tests now.
          Hide
          Tom White added a comment -

          I'm getting the same - nodeMetadata.getGroup() is returning null for the second node in the cluster.

          Show
          Tom White added a comment - I'm getting the same - nodeMetadata.getGroup() is returning null for the second node in the cluster.
          Hide
          Andrei Savu added a comment -

          I've created a patch from the changes Adrian suggested. Tested with ZK on EC2. I'm going to test HBase.

          Show
          Andrei Savu added a comment - I've created a patch from the changes Adrian suggested. Tested with ZK on EC2. I'm going to test HBase.
          Hide
          Adrian Cole added a comment -

          @tom thanks for the pointer.. I was looking for a .log file, and missed the checkstyle-result.xml!

          @all thanks for testing

          Show
          Adrian Cole added a comment - @tom thanks for the pointer.. I was looking for a .log file, and missed the checkstyle-result.xml! @all thanks for testing
          Hide
          Tom White added a comment -

          I can confirm that this fixes ZK launch. However, destroy doesn't work for the same reason, since DestroyClusterAction uses group names to select which instances to shutdown, so only the first in each group is selected. Not sure there's a workaround for this.

          Show
          Tom White added a comment - I can confirm that this fixes ZK launch. However, destroy doesn't work for the same reason, since DestroyClusterAction uses group names to select which instances to shutdown, so only the first in each group is selected. Not sure there's a workaround for this.
          Hide
          Adrian Cole added a comment -

          patch includes a parser fix for jclouds 1.1.0

          Show
          Adrian Cole added a comment - patch includes a parser fix for jclouds 1.1.0
          Hide
          Adrian Cole added a comment -

          I've tested this on aws-ec2 for cassandra and zookeeper using the jclouds 1.1.1-SNAPSHOT version, which is the same as 1.1.0 except including the following fix: http://code.google.com/p/jclouds/issues/detail?id=660

          Show
          Adrian Cole added a comment - I've tested this on aws-ec2 for cassandra and zookeeper using the jclouds 1.1.1-SNAPSHOT version, which is the same as 1.1.0 except including the following fix: http://code.google.com/p/jclouds/issues/detail?id=660
          Hide
          Tom White added a comment -

          Thanks for the patch Adrian. ZK starts up correctly (I can use a 4 letter word to interrogate both instances in a cluster), and shuts down correctly. The integration test is still failing for me however, with the following error repeating indefinitely:

          2011-08-16 10:21:06,376 WARN  [org.apache.zookeeper.ClientCnxn] (main-SendThread(ec2-107-20-63-131.compute-1.amazonaws.com:2181)) Session 0x0 for server null, unexpected error, closing socket connection and attempting reconnect
          java.net.ConnectException: Connection refused
          	at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
          	at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
          	at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
          
          Show
          Tom White added a comment - Thanks for the patch Adrian. ZK starts up correctly (I can use a 4 letter word to interrogate both instances in a cluster), and shuts down correctly. The integration test is still failing for me however, with the following error repeating indefinitely: 2011-08-16 10:21:06,376 WARN [org.apache.zookeeper.ClientCnxn] (main-SendThread(ec2-107-20-63-131.compute-1.amazonaws.com:2181)) Session 0x0 for server null, unexpected error, closing socket connection and attempting reconnect java.net.ConnectException: Connection refused at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
          Hide
          Adrian Cole added a comment -

          jclouds is going to push out an emergency release for 1.1.1. I suggest we block on this as opposed to coding in the parser fix. The parser that is referenced is likely to change in jclouds 1.2.0, so packaging in a patch would make whirr 0.6.0 incompatible with jclouds 1.2.0.

          http://groups.google.com/group/jclouds-dev/browse_thread/thread/74150d764cc70a02

          Show
          Adrian Cole added a comment - jclouds is going to push out an emergency release for 1.1.1. I suggest we block on this as opposed to coding in the parser fix. The parser that is referenced is likely to change in jclouds 1.2.0, so packaging in a patch would make whirr 0.6.0 incompatible with jclouds 1.2.0. http://groups.google.com/group/jclouds-dev/browse_thread/thread/74150d764cc70a02
          Hide
          Adrian Cole added a comment -

          tested patch using jclouds 1.1.1

          Show
          Adrian Cole added a comment - tested patch using jclouds 1.1.1
          Hide
          Andrei Savu added a comment -

          looks good to me. integration tests pass for zookeeper and all instances are terminated as expected.

          Show
          Andrei Savu added a comment - looks good to me. integration tests pass for zookeeper and all instances are terminated as expected.
          Hide
          Tom White added a comment -

          I tried the latest patch and a ZK cluster starts OK (I get 'imok' back from each server), even though the integration test still fails in the same way as before. Since it works for others, this is not a blocker for release, although it would be nice to find out what's going on here.

          Show
          Tom White added a comment - I tried the latest patch and a ZK cluster starts OK (I get 'imok' back from each server), even though the integration test still fails in the same way as before. Since it works for others, this is not a blocker for release, although it would be nice to find out what's going on here.
          Hide
          Adrian Cole added a comment -

          @tom is this a WARN that happens once or repeatedly? does the actual maven execution fail, or are you referring to connection refused notices. Are you using aws-ec2 with the default properties in the project or overrides?

          Show
          Adrian Cole added a comment - @tom is this a WARN that happens once or repeatedly? does the actual maven execution fail, or are you referring to connection refused notices. Are you using aws-ec2 with the default properties in the project or overrides?
          Hide
          Tom White added a comment -

          The WARN happens repeatedly and doesn't terminate. I am setting whirr.test.provider to "aws-ec2" and I have applied WHIRR-341.

          Show
          Tom White added a comment - The WARN happens repeatedly and doesn't terminate. I am setting whirr.test.provider to "aws-ec2" and I have applied WHIRR-341 .
          Hide
          Tom White added a comment -

          The test passed for me in the us-west-1 region (set using whirr.location-id=us-west-1 in the property file).

          Show
          Tom White added a comment - The test passed for me in the us-west-1 region (set using whirr.location-id=us-west-1 in the property file).
          Hide
          Andrei Savu added a comment -

          Tested again and it seems like the integration tests for ZooKeeper & Cassandra pass as expected on ec2 us-east-1. I believe we experienced a brief service glitch today. +1 for committing WHIRR-341 & latest patch for WHIRR-361.

          Show
          Andrei Savu added a comment - Tested again and it seems like the integration tests for ZooKeeper & Cassandra pass as expected on ec2 us-east-1. I believe we experienced a brief service glitch today. +1 for committing WHIRR-341 & latest patch for WHIRR-361 .
          Hide
          Adrian Cole added a comment -

          +1

          Show
          Adrian Cole added a comment - +1
          Hide
          Andrei Savu added a comment -

          I've just committed the last patch.

          Show
          Andrei Savu added a comment - I've just committed the last patch.

            People

            • Assignee:
              Adrian Cole
              Reporter:
              Adrian Cole
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 0.5h
                0.5h
                Remaining:
                Remaining Estimate - 0.5h
                0.5h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development