Uploaded image for project: 'Accumulo'
  1. Accumulo
  2. ACCUMULO-1933

Make unit on memory parameters case-insensitive

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4.4, 1.5.0
    • Fix Version/s: 1.4.5, 1.5.1, 1.6.0
    • Component/s: shell
    • Labels:

      Description

      config -t my_table -s table.split.threshold=2g fails with a non-intuitive error.

      config -t my_table -s table.split.threshold=2G succeeds

      It would be nice for both to work.

      1. ACCUMULO-1933.2.patch
        5 kB
        Theodore michael Malaska
      2. ACCUMULO-1933.1.patch
        5 kB
        Theodore michael Malaska
      3. ACCUMULO-1933.patch
        3 kB
        Theodore michael Malaska

        Activity

        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 65d5fba87830191844d3812d0ce3ca0a415be6e2 in branch refs/heads/1.6.0-SNAPSHOT from Theodore michael Malaska
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=65d5fba ]

        ACCUMULO-1933 Make unit on memory parameters case-insensitive.

        1. Added support for both cases for G, M, K and B

        2. Added warning message for lower case b and that the code will consider this bytes

        3. Added meaningful error message for any number formatting issues

        4. Added unit test that test 1 and 3 from above.

        modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java

        new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java

        Show
        jira-bot ASF subversion and git services added a comment - Commit 65d5fba87830191844d3812d0ce3ca0a415be6e2 in branch refs/heads/1.6.0-SNAPSHOT from Theodore michael Malaska [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=65d5fba ] ACCUMULO-1933 Make unit on memory parameters case-insensitive. 1. Added support for both cases for G, M, K and B 2. Added warning message for lower case b and that the code will consider this bytes 3. Added meaningful error message for any number formatting issues 4. Added unit test that test 1 and 3 from above. modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 65d5fba87830191844d3812d0ce3ca0a415be6e2 in branch refs/heads/1.5.1-SNAPSHOT from Theodore michael Malaska
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=65d5fba ]

        ACCUMULO-1933 Make unit on memory parameters case-insensitive.

        1. Added support for both cases for G, M, K and B

        2. Added warning message for lower case b and that the code will consider this bytes

        3. Added meaningful error message for any number formatting issues

        4. Added unit test that test 1 and 3 from above.

        modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java

        new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java

        Show
        jira-bot ASF subversion and git services added a comment - Commit 65d5fba87830191844d3812d0ce3ca0a415be6e2 in branch refs/heads/1.5.1-SNAPSHOT from Theodore michael Malaska [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=65d5fba ] ACCUMULO-1933 Make unit on memory parameters case-insensitive. 1. Added support for both cases for G, M, K and B 2. Added warning message for lower case b and that the code will consider this bytes 3. Added meaningful error message for any number formatting issues 4. Added unit test that test 1 and 3 from above. modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java
        Hide
        mdrob Mike Drob added a comment -

        John Vines - Thanks for rolling this in. Next time, can you also use the --signoff option of git am? It makes it easier to track who is doing what. Thanks!

        Show
        mdrob Mike Drob added a comment - John Vines - Thanks for rolling this in. Next time, can you also use the --signoff option of git am ? It makes it easier to track who is doing what. Thanks!
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit f43ba3bb77f3cdcff365348252f9504be9dc3a60 in branch refs/heads/master from Theodore michael Malaska
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f43ba3b ]

        ACCUMULO-1933 Make unit on memory parameters case-insensitive.

        1. Added support for both cases for G, M, K and B

        2. Added warning message for lower case b and that the code will consider this bytes

        3. Added meaningful error message for any number formatting issues

        4. Added unit test that test 1 and 3 from above.

        modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java

        new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java

        Show
        jira-bot ASF subversion and git services added a comment - Commit f43ba3bb77f3cdcff365348252f9504be9dc3a60 in branch refs/heads/master from Theodore michael Malaska [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f43ba3b ] ACCUMULO-1933 Make unit on memory parameters case-insensitive. 1. Added support for both cases for G, M, K and B 2. Added warning message for lower case b and that the code will consider this bytes 3. Added meaningful error message for any number formatting issues 4. Added unit test that test 1 and 3 from above. modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java
        Hide
        vines John Vines added a comment -

        Looks good, patch has been rolled in!

        Show
        vines John Vines added a comment - Looks good, patch has been rolled in!
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit f43ba3bb77f3cdcff365348252f9504be9dc3a60 in branch refs/heads/1.6.0-SNAPSHOT from Theodore michael Malaska
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f43ba3b ]

        ACCUMULO-1933 Make unit on memory parameters case-insensitive.

        1. Added support for both cases for G, M, K and B

        2. Added warning message for lower case b and that the code will consider this bytes

        3. Added meaningful error message for any number formatting issues

        4. Added unit test that test 1 and 3 from above.

        modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java

        new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java

        Show
        jira-bot ASF subversion and git services added a comment - Commit f43ba3bb77f3cdcff365348252f9504be9dc3a60 in branch refs/heads/1.6.0-SNAPSHOT from Theodore michael Malaska [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f43ba3b ] ACCUMULO-1933 Make unit on memory parameters case-insensitive. 1. Added support for both cases for G, M, K and B 2. Added warning message for lower case b and that the code will consider this bytes 3. Added meaningful error message for any number formatting issues 4. Added unit test that test 1 and 3 from above. modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit f43ba3bb77f3cdcff365348252f9504be9dc3a60 in branch refs/heads/1.5.1-SNAPSHOT from Theodore michael Malaska
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f43ba3b ]

        ACCUMULO-1933 Make unit on memory parameters case-insensitive.

        1. Added support for both cases for G, M, K and B

        2. Added warning message for lower case b and that the code will consider this bytes

        3. Added meaningful error message for any number formatting issues

        4. Added unit test that test 1 and 3 from above.

        modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java

        new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java

        Show
        jira-bot ASF subversion and git services added a comment - Commit f43ba3bb77f3cdcff365348252f9504be9dc3a60 in branch refs/heads/1.5.1-SNAPSHOT from Theodore michael Malaska [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=f43ba3b ] ACCUMULO-1933 Make unit on memory parameters case-insensitive. 1. Added support for both cases for G, M, K and B 2. Added warning message for lower case b and that the code will consider this bytes 3. Added meaningful error message for any number formatting issues 4. Added unit test that test 1 and 3 from above. modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 65d5fba87830191844d3812d0ce3ca0a415be6e2 in branch refs/heads/1.4.5-SNAPSHOT from Theodore michael Malaska
        [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=65d5fba ]

        ACCUMULO-1933 Make unit on memory parameters case-insensitive.

        1. Added support for both cases for G, M, K and B

        2. Added warning message for lower case b and that the code will consider this bytes

        3. Added meaningful error message for any number formatting issues

        4. Added unit test that test 1 and 3 from above.

        modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java

        new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java

        Show
        jira-bot ASF subversion and git services added a comment - Commit 65d5fba87830191844d3812d0ce3ca0a415be6e2 in branch refs/heads/1.4.5-SNAPSHOT from Theodore michael Malaska [ https://git-wip-us.apache.org/repos/asf?p=accumulo.git;h=65d5fba ] ACCUMULO-1933 Make unit on memory parameters case-insensitive. 1. Added support for both cases for G, M, K and B 2. Added warning message for lower case b and that the code will consider this bytes 3. Added meaningful error message for any number formatting issues 4. Added unit test that test 1 and 3 from above. modified: src/core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfiguration.java new file: src/core/src/test/java/org/apache/accumulo/core/conf/AccumuloConfigurationTest.java
        Hide
        ted.m Theodore michael Malaska added a comment -

        Thanks

        Show
        ted.m Theodore michael Malaska added a comment - Thanks
        Hide
        ctubbsii Christopher Tubbs added a comment -

        Now, a committer should review the patch and apply it for you when they have time, if it looks alright. If it merges cleanly forward to 1.5.1 and 1.6.0 branches, that's it. If not, we may come back and ask you to provide a separate patch to apply to those branches... or we may just resolve the merge conflicts ourselves.

        Show
        ctubbsii Christopher Tubbs added a comment - Now, a committer should review the patch and apply it for you when they have time, if it looks alright. If it merges cleanly forward to 1.5.1 and 1.6.0 branches, that's it. If not, we may come back and ask you to provide a separate patch to apply to those branches... or we may just resolve the merge conflicts ourselves.
        Hide
        ted.m Theodore michael Malaska added a comment -

        Thanks Chris,

        What is the next steps?

        Show
        ted.m Theodore michael Malaska added a comment - Thanks Chris, What is the next steps?
        Hide
        ted.m Theodore michael Malaska added a comment -

        Applied the changes correctly this time

        Show
        ted.m Theodore michael Malaska added a comment - Applied the changes correctly this time
        Hide
        ted.m Theodore michael Malaska added a comment -

        Wait I need to make one more change

        Show
        ted.m Theodore michael Malaska added a comment - Wait I need to make one more change
        Hide
        ted.m Theodore michael Malaska added a comment -

        Made the change Sean B. Requested

        Show
        ted.m Theodore michael Malaska added a comment - Made the change Sean B. Requested
        Hide
        busbey Sean Busbey added a comment -

        Thanks Ted!

        Could you update the new test file to include an ASF license header?

        A few suggested improvements:

        • how about IllegalArgumentException instead of generic RuntimeException?
        • please break the two failure cases into their own tests that use JUnit's expected exception argument to hte Test annotation

        Also, please make sure you're creating the patch with the "git diff" args given in our contributor guide so that a committer can easily attribute the commit to you.

        Show
        busbey Sean Busbey added a comment - Thanks Ted! Could you update the new test file to include an ASF license header? A few suggested improvements: how about IllegalArgumentException instead of generic RuntimeException? please break the two failure cases into their own tests that use JUnit's expected exception argument to hte Test annotation Also, please make sure you're creating the patch with the "git diff" args given in our contributor guide so that a committer can easily attribute the commit to you.
        Hide
        ted.m Theodore michael Malaska added a comment -

        The following is in this patch:

        1. Added support for both cases for G, M, K and B
        2. Added warning message for lower case b and that the code will consider this bytes
        3. Added meaningful error message for any number formatting issues
        4. Added unit test that test 1 and 3 from above.

        Show
        ted.m Theodore michael Malaska added a comment - The following is in this patch: 1. Added support for both cases for G, M, K and B 2. Added warning message for lower case b and that the code will consider this bytes 3. Added meaningful error message for any number formatting issues 4. Added unit test that test 1 and 3 from above.
        Hide
        elserj Josh Elser added a comment -

        We could also give more informative error messages in the case of unrecognized units...

        Would be nice to improve the error message for completely unrecognized units like config -t my_table -s table.split.threshold=2A

        Oh yes, please ^^

        Also a general +1 for "follow Java" over SI units. Doing this for K, M and G is fine by me too with the b/B caveats.

        Show
        elserj Josh Elser added a comment - We could also give more informative error messages in the case of unrecognized units... Would be nice to improve the error message for completely unrecognized units like config -t my_table -s table.split.threshold=2A Oh yes, please ^^ Also a general +1 for "follow Java" over SI units. Doing this for K, M and G is fine by me too with the b/B caveats.
        Hide
        ted.m Theodore michael Malaska added a comment -

        I can do that too. Thanks Keith

        Show
        ted.m Theodore michael Malaska added a comment - I can do that too. Thanks Keith
        Hide
        kturner Keith Turner added a comment -

        I never knew there was a B option. I have attempted to use lower case memory units a few times before, I will utilize this change. Would be nice to improve the error message for completely unrecognized units like config -t my_table -s table.split.threshold=2A

        Show
        kturner Keith Turner added a comment - I never knew there was a B option. I have attempted to use lower case memory units a few times before, I will utilize this change. Would be nice to improve the error message for completely unrecognized units like config -t my_table -s table.split.threshold=2A
        Hide
        ted.m Theodore michael Malaska added a comment -

        Deal.

        I will write the code now

        Show
        ted.m Theodore michael Malaska added a comment - Deal. I will write the code now
        Hide
        ctubbsii Christopher Tubbs added a comment -

        Perhaps we can tolerate 'b' also, but give a warning indicating that we're assuming they meant "bytes"?

        Show
        ctubbsii Christopher Tubbs added a comment - Perhaps we can tolerate 'b' also, but give a warning indicating that we're assuming they meant "bytes"?
        Hide
        ctubbsii Christopher Tubbs added a comment -

        I also like #2, but not convinced it's worth deprecating, as Sean Busbey suggests... I think I'd rather extend the existing tolerance to include the JVM grammar as a subset, not to match it exactly. I think there's still utility in being able to express the base unit explicitly.

        Show
        ctubbsii Christopher Tubbs added a comment - I also like #2, but not convinced it's worth deprecating, as Sean Busbey suggests... I think I'd rather extend the existing tolerance to include the JVM grammar as a subset, not to match it exactly. I think there's still utility in being able to express the base unit explicitly.
        Hide
        busbey Sean Busbey added a comment -

        I like #2, with a slight mod: could we mark B as deprecated in docs (favoring no label to be consistent with the JVM) and issue a WARN that says as much?

        Show
        busbey Sean Busbey added a comment - I like #2, with a slight mod: could we mark B as deprecated in docs (favoring no label to be consistent with the JVM) and issue a WARN that says as much?
        Hide
        ted.m Theodore michael Malaska added a comment -

        I don't think I can omit "B" and still be backwards compatible.

        If I leave "b" as is, then the code errors out currently. Hmm

        I think I have two options:
        1. Support G, M, K, and B in all cases
        2. Support G, M, and K in all cases but B only in upper case and add a clean error message for b

        What do you think. I'm open to both.

        Show
        ted.m Theodore michael Malaska added a comment - I don't think I can omit "B" and still be backwards compatible. If I leave "b" as is, then the code errors out currently. Hmm I think I have two options: 1. Support G, M, K, and B in all cases 2. Support G, M, and K in all cases but B only in upper case and add a clean error message for b What do you think. I'm open to both.
        Hide
        ctubbsii Christopher Tubbs added a comment -

        We could also give more informative error messages in the case of unrecognized units...

        Show
        ctubbsii Christopher Tubbs added a comment - We could also give more informative error messages in the case of unrecognized units...
        Hide
        ctubbsii Christopher Tubbs added a comment -

        Currently, omitting the "B" implies bytes, as that's the basic unit of memory, so maybe there's no need to support another way to specify "bytes"? There is currently no way to specify "bits" (because, as pointed out, that doesn't make sense). However, I still kinda think allowing "b" is confusing to treat as "bytes"... especially if you get a pedantic networking person configuring Accumulo.

        Perhaps a good compromise is to allow "K", "M", and "G" to be case-insensitive (to permit JVM configuration syntax), and leave "B" alone (I'm not sure JVM even recognizes "B")? We could continue to document the upper-case as a preference, but be more tolerant of lower-case, for these. That would satisfy the vast majority of cases, anyway, since the whole reason for being able to specify units is to make it easier to specify kilobytes, megabytes, and gigabytes... not bytes.

        Show
        ctubbsii Christopher Tubbs added a comment - Currently, omitting the "B" implies bytes, as that's the basic unit of memory, so maybe there's no need to support another way to specify "bytes"? There is currently no way to specify "bits" (because, as pointed out, that doesn't make sense). However, I still kinda think allowing "b" is confusing to treat as "bytes"... especially if you get a pedantic networking person configuring Accumulo. Perhaps a good compromise is to allow "K", "M", and "G" to be case-insensitive (to permit JVM configuration syntax), and leave "B" alone (I'm not sure JVM even recognizes "B")? We could continue to document the upper-case as a preference, but be more tolerant of lower-case, for these. That would satisfy the vast majority of cases, anyway, since the whole reason for being able to specify units is to make it easier to specify kilobytes, megabytes, and gigabytes... not bytes.
        Hide
        ted.m Theodore michael Malaska added a comment -

        Yeah I looked at Java. Seem to be both cases and I don't see how to set memory in bits. Bytes is the default.

        Show
        ted.m Theodore michael Malaska added a comment - Yeah I looked at Java. Seem to be both cases and I don't see how to set memory in bits. Bytes is the default.
        Hide
        busbey Sean Busbey added a comment -

        I think memory is something that's dealt with in a non-SI way on a sufficient number of other systems that we should match the behavior of the other configurable components.

        Nothing else I know of includes a unit marker for bytes themselves, so I'm less concerned about matching. However, it is going to be confusing to many users for "b" to give them 1/8 the number they include, esp. if all the other units are insensitive. I don't think there's a sufficient use case for specifying memory amounts in bits, so I'd prefer to just treat both b and B as bytes.

        Show
        busbey Sean Busbey added a comment - I think memory is something that's dealt with in a non-SI way on a sufficient number of other systems that we should match the behavior of the other configurable components. Nothing else I know of includes a unit marker for bytes themselves, so I'm less concerned about matching. However, it is going to be confusing to many users for "b" to give them 1/8 the number they include, esp. if all the other units are insensitive. I don't think there's a sufficient use case for specifying memory amounts in bits, so I'd prefer to just treat both b and B as bytes.
        Hide
        ted.m Theodore michael Malaska added a comment -

        I like following java. Let me see how they handle "b" to "B". Give me a couple of minutes

        Thanks Christopher. I'm really interested in contributing to Accumulo. Thanks for to opportunity.

        Show
        ted.m Theodore michael Malaska added a comment - I like following java. Let me see how they handle "b" to "B". Give me a couple of minutes Thanks Christopher. I'm really interested in contributing to Accumulo. Thanks for to opportunity.
        Hide
        ctubbsii Christopher Tubbs added a comment -

        I added this convenience feature for memory units at the same time as the time units, which are definitely SI. So, I guess there's a choice we have to make... do we want to try to stick to SI for everything, or are memory units sufficiently distinct, to support a wider range of (non-fractional) unit declarations?

        Second, if we do think that memory units are sufficiently different, and to the extent that it makes sense to support the case-insensitive JVM precedent, how do we deal with "b" vs. "B" for bytes?

        Theodore michael Malaska: since you've expressed a willingness to work on this, what are your thoughts?

        Show
        ctubbsii Christopher Tubbs added a comment - I added this convenience feature for memory units at the same time as the time units, which are definitely SI. So, I guess there's a choice we have to make... do we want to try to stick to SI for everything, or are memory units sufficiently distinct, to support a wider range of (non-fractional) unit declarations? Second, if we do think that memory units are sufficiently different, and to the extent that it makes sense to support the case-insensitive JVM precedent, how do we deal with "b" vs. "B" for bytes? Theodore michael Malaska : since you've expressed a willingness to work on this, what are your thoughts?
        Hide
        busbey Sean Busbey added a comment -

        The JVM accepts both upper and lower case for memory arguments, it does not use SI units. I think we're much less likely to confuse users if we maintain consistency with that.

        Show
        busbey Sean Busbey added a comment - The JVM accepts both upper and lower case for memory arguments , it does not use SI units. I think we're much less likely to confuse users if we maintain consistency with that.
        Hide
        ctubbsii Christopher Tubbs added a comment -

        I'm actually somewhat opposed to this ticket. The SI-prefixes (and "B" for bytes) I used for this are case-sensitive for a reason. "B", for instance means "bytes", vs. "b", which means "bits". "M" means "mega", vs. "m" which means "milli". "P" for "peta", vs. "p" for "pico".

        Now, in the context of memory, I realize it doesn't make sense to have a "millibyte" or a "picobyte" ("B" for byte rather than "b" still applies, though), but I'd strongly prefer to stick to the SI case-sensitive precedent.

        That said, the proper prefix for "kilo" is "k" (lower-case), not "K". However, there is no SI unit for upper-case "K" in conflict, and in computer networking, it is not unusual to see both "kbps" and "Kbps" for "kilobits per second". We could make the "k" case-insensitive.

        Coming from a physics background, I think it's quite important to recognize that case matters in units, and I'd rather encourage people to use SI-prefixes when possible, for maximum clarity, than to introduce ambiguity that requires context (such as asking the question, "does milli- make sense here?") to resolve.

        Show
        ctubbsii Christopher Tubbs added a comment - I'm actually somewhat opposed to this ticket. The SI-prefixes (and "B" for bytes) I used for this are case-sensitive for a reason. "B", for instance means "bytes", vs. "b", which means "bits". "M" means "mega", vs. "m" which means "milli". "P" for "peta", vs. "p" for "pico". Now, in the context of memory, I realize it doesn't make sense to have a "millibyte" or a "picobyte" ("B" for byte rather than "b" still applies, though), but I'd strongly prefer to stick to the SI case-sensitive precedent. That said, the proper prefix for "kilo" is "k" (lower-case), not "K". However, there is no SI unit for upper-case "K" in conflict, and in computer networking, it is not unusual to see both "kbps" and "Kbps" for "kilobits per second". We could make the "k" case-insensitive. Coming from a physics background, I think it's quite important to recognize that case matters in units, and I'd rather encourage people to use SI-prefixes when possible, for maximum clarity, than to introduce ambiguity that requires context (such as asking the question, "does milli- make sense here?") to resolve.
        Hide
        ted.m Theodore michael Malaska added a comment -

        I'm new to Accumulo and this looks like a great jira to start with.

        I have downloaded the code and built it. I have also found the fix. I will make the changes and submit a patch today.

        Show
        ted.m Theodore michael Malaska added a comment - I'm new to Accumulo and this looks like a great jira to start with. I have downloaded the code and built it. I have also found the fix. I will make the changes and submit a patch today.

          People

          • Assignee:
            ted.m Theodore michael Malaska
            Reporter:
            elserj Josh Elser
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development