[jira] [Assigned] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister reassigned CASSANDRA-13047: - Assignee: (was: Patrick Bannister) > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Priority: Normal > Fix For: 4.0 > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17103311#comment-17103311 ] Patrick Bannister commented on CASSANDRA-13047: --- It looks like the versioned docs website has progressed enough that this ticket could be completed. However, I should hand it off to somebody with more free time to work on it. > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Normal > Fix For: 4.0 > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15659) Better support of Python 3 for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-15659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071980#comment-17071980 ] Patrick Bannister commented on CASSANDRA-15659: --- I don't plan to work this ticket, but I'm posting to share some relevant context that may be useful. Testing was the main reason we limited Python 3.x support by minor version. The cqlsh dtests are costly in terms of time and compute resources. Unfortunately, most of the substantive testing of cqlsh is in the dtests. In the past, the thinking was to expand the Python 3.x minor versions supported by cqlsh after dropping Python 2 support. The idea was to limit the number of test environments needed to properly test cqlsh. [SaferScanner|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/saferscanner.py] is another problem. It depends on implementation details of the Python re module, and it's sensitive to the Python minor version. We had to rewrite it twice in the past two years. > Better support of Python 3 for cqlsh > > > Key: CASSANDRA-15659 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15659 > Project: Cassandra > Issue Type: Task > Components: Tool/cqlsh >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-alpha > > > From mailing list: > [https://lists.apache.org/thread.html/r377099b632c62b641e4feef5b738084fc5369b0c7157fae867853597%40%3Cdev.cassandra.apache.org%3E] > > As of today (24/3/2020) and current trunk, there is Python 3.6 supported (1) > but there is not any 3.6 version ootb in Debian for example. E.g. Buster has > Python 3.7 and other (recent) releases have version 2.7. This means that if > one wants to use Python 3 in Debian, he has to use 3.6 but it is not in the > repository so he has to download / compile / install it on his own. > There should be some sane Python 3 version supported which is as well present > in Debian repository (or requirement to run with 3.6 should be relaxed) . > (1) > [https://github.com/apache/cassandra/blob/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79/bin/cqlsh#L57-L65] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10190) Python 3 support for cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928785#comment-16928785
]
Patrick Bannister edited comment on CASSANDRA-10190 at 9/13/19 1:23 AM:
I'm experimenting with the {{test_cqlsh_completion}} unit tests to try to make
them faster and more like unit tests. Right now they work more like dtests (as
do most of the cqlshlib unit tests).
This is not worth holding up the ticket to do, but I'll push the results up to
the branch if I can finish something before we're ready to proceed.
was (Author: ptbannister):
I'm experimenting with changing the cqlshlib unit tests in
{{test_cqlsh_completion}}. These are the slowest part of the cqlshlib unit test
suite. They currently work by running cqlsh in a subprocess to connect to a ccm
cluster, sending partial commands to the cqlsh, and reading the completions
suggested by the cqlsh. This is slow, because we have to use a timeout to wait
for the cqlsh to accept our input and output its recommended completions.
In general, these don't really look like unit tests, they look more like
dtests. One approach would be to remove this from the unit tests and make it
part of the dtests. But I'd prefer to convert them to something more like a
unit test. We can make them run faster by using cqlshlib internals directly,
instead of running cqlsh in a subprocess. We can call {{cql_complete}} on each
partial command and assert that the completions are what we expect.
Once I've rewritten the {{test_cqlsh_completion.py}} tests like this, it'll be
up on the branch for consideration.
> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh.
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a
> .python-version containing "2.7". But it would be nice if cqlsh supported
> modern Python versions out of the box.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928785#comment-16928785
]
Patrick Bannister commented on CASSANDRA-10190:
---
I'm experimenting with changing the cqlshlib unit tests in
{{test_cqlsh_completion}}. These are the slowest part of the cqlshlib unit test
suite. They currently work by running cqlsh in a subprocess to connect to a ccm
cluster, sending partial commands to the cqlsh, and reading the completions
suggested by the cqlsh. This is slow, because we have to use a timeout to wait
for the cqlsh to accept our input and output its recommended completions.
In general, these don't really look like unit tests, they look more like
dtests. One approach would be to remove this from the unit tests and make it
part of the dtests. But I'd prefer to convert them to something more like a
unit test. We can make them run faster by using cqlshlib internals directly,
instead of running cqlsh in a subprocess. We can call {{cql_complete}} on each
partial command and assert that the completions are what we expect.
Once I've rewritten the {{test_cqlsh_completion.py}} tests like this, it'll be
up on the branch for consideration.
> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh.
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a
> .python-version containing "2.7". But it would be nice if cqlsh supported
> modern Python versions out of the box.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916262#comment-16916262
]
Patrick Bannister commented on CASSANDRA-10190:
---
I added new unit tests for the {{get_ranges}} function of
{{cqlshlib.copyutil.ExportTask}}. The tests exposed a bug in {{get_ranges}}, so
I fixed that too.
> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh.
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a
> .python-version containing "2.7". But it would be nice if cqlsh supported
> modern Python versions out of the box.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895682#comment-16895682
]
Patrick Bannister commented on CASSANDRA-10190:
---
[~djoshi3] the behavior of the {{make_range}} function was different under
Python 2.7 and Python 3.6. For a quick demonstration of the reason, try running
this in a Python 2 interpreter, and then again in a Python 3 interpreter:
{code:python}
assert 0 > None
{code}
Under Python 2 this is fine, but under Python 3, attempting to compare
{{NoneType}} to anything else will throw a {{TypeError}}.
This problem was exposed by failures in the dtest
{{test_writing_with_token_boundaries}} (from cqlsh_tests/test_cqlsh_copy.py).
When the test ran the COPY command with the WITH BEGINTOKEN and WITH ENDTOKEN
options, cqlsh crashed because of the {{TypeError}}.
I like the idea of adding some unit tests around this, I'll do it next time I
get a solid hour to work on this.
> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: cqlsh
> Attachments: coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh.
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a
> .python-version containing "2.7". But it would be nice if cqlsh supported
> modern Python versions out of the box.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883359#comment-16883359 ] Patrick Bannister commented on CASSANDRA-10190: --- Rebased my dtest branch on the latest dtest master, no regressions in the cqlsh tests. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883278#comment-16883278 ] Patrick Bannister commented on CASSANDRA-10190: --- I rebased my cassandra branch on the latest trunk, addressed some failures in the dtests, and introduced a new --python option to the `cqlsh` launcher script so that a user may specify the path to a Python interpreter that they would like to use to run cqlsh. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16882929#comment-16882929 ] Patrick Bannister commented on CASSANDRA-10190: --- [~spo...@gmail.com], yes, those are the current branches. For this ticket, the immediate goals are: * Port cqlshlib to run on Python 3.6 and Python 2.7 * Get the cqlshlib unit tests to parity between Python 2.7 and Python 3.6, except for documented cases with external problems, such as cases where Python 3 breaks the driver The dtest branch we're using doesn't enable the remaining dtests, it only gets the currently enabled dtests working. I would like to merge these changes to get cqlshlib ported first, before taking on the remaining dtests. It's more urgent to port cqlshlib. It would also help manage the scope of the problem to take care of cqlshlib before dealing with the remaining dtests. As for breaking out the cqlshlib tests, my recommendation is to continue delivering them as part of cqlshlib itself, because it feels wrong to break the tests away from the repo. But we can address this question separately, on CASSANDRA-14990. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866010#comment-16866010 ] Patrick Bannister commented on CASSANDRA-10190: --- [~djoshi3], I studied the two failures in the dtest cqlsh_tests. I was able to address one. For the other, I suggest we do a fresh run and see if it recurs. Details below for posterity. The failure in test_writing_with_token_boundaries was a Python 3 specific bug in the token range calculation function in cqlshlib copyutil.py, I pushed a fix to the branch to address it. The failure in test_reading_max_insert_errors was deeper than cqlshlib - it was a warning message from one of the Cassandra nodes about garbage collection of an unreleased ByteBuf in the Netty epollEventLoopGroup. The test where this happened intentionally causes some errors to occur with the COPY FROM command, so this might be an indication that we're not cleaning up properly under certain error conditions exercised by this test. This might be worth investigating, but I'd say it's not a cqlshlib issue. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859468#comment-16859468 ] Patrick Bannister edited comment on CASSANDRA-10190 at 6/9/19 2:15 PM: --- [~djoshi3], thanks for the feedback. I've incorporated all of your recommendations on the branch. I meant to completely delete FrozenType after testing with it commented out, but I forgot to follow through. The reason I wanted to remove the FrozenType class from cqlsh.py is because it was commented "Needed until the bundled python driver adds FrozenType.", and I noticed that [the Python driver includes FrozenType since version 2.5.0|https://github.com/datastax/python-driver/blob/master/CHANGELOG.rst#250]. It looks like the bundled driver is at least version 3.7.0 (CASSANDRA-12736), so I think we should be able to remove FrozenType completely. I've made this change on my branch too. was (Author: ptbannister): [~djoshi3], thanks for the feedback. I've incorporated all of your recommendations on the branch. I meant to completely delete FrozenType after testing with it commented out, but I forgot to follow through. The reason I wanted to remove the FrozenType class from cqlsh.py is because it was commented "Needed until the bundled python driver adds FrozenType.", and I noticed that [the Python driver includes FrozenType since version 2.5.0|[https://github.com/datastax/python-driver/blob/master/CHANGELOG.rst#250].] It looks like the bundled driver is at least version 3.7.0 (CASSANDRA-12736), so I think we should be able to remove FrozenType completely. I've made this change on my branch too. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16859468#comment-16859468 ] Patrick Bannister commented on CASSANDRA-10190: --- [~djoshi3], thanks for the feedback. I've incorporated all of your recommendations on the branch. I meant to completely delete FrozenType after testing with it commented out, but I forgot to follow through. The reason I wanted to remove the FrozenType class from cqlsh.py is because it was commented "Needed until the bundled python driver adds FrozenType.", and I noticed that [the Python driver includes FrozenType since version 2.5.0|[https://github.com/datastax/python-driver/blob/master/CHANGELOG.rst#250].] It looks like the bundled driver is at least version 3.7.0 (CASSANDRA-12736), so I think we should be able to remove FrozenType completely. I've made this change on my branch too. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14494) Investigate possibility of a cqlsh terminfo
[
https://issues.apache.org/jira/browse/CASSANDRA-14494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Bannister updated CASSANDRA-14494:
--
Resolution: Won't Do
Status: Resolved (was: Open)
This is unnecessary at this time.
> Investigate possibility of a cqlsh terminfo
> ---
>
> Key: CASSANDRA-14494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14494
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Tools
> Environment: This behavior has been observed in xterm on CentOS 7.5
> platforms. The test_cqlsh_output.py unit tests
> (pylib/cqlshlib/test/test_cqlsh_output.py) are a good place to see it in
> action.
>Reporter: Patrick Bannister
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: Python, cqlsh, test
> Fix For: 4.x
>
>
> Summary: investigate whether we could use a cqlsh-specific terminfo file to
> prevent use of the set-meta-mode escape sequence in xterm without breaking
> colors. If it works, see if we can install it in an appropriate place using
> Python distutils. If yes to both, generate a cqlsh terminfo file and work it
> into the install process.
> Long detailed explanation:
> In some more recent environments, in Python REPL applications that use the
> readline module, the set meta mode escape sequence is output before each
> prompt. This escape sequence has caused problems for some applications, and
> in our case, some of our cqlsh unit tests
> (pylib/cqlshlib/test/test_cqlsh_output.py) choke on this output because of
> the way our tests are designed to detect the cqlsh prompt. This behavior was
> observed on a CentOS 7.5 platform.
> The set-meta-mode escape sequence normally appears as "[?1034h" in output;
> it's normally defined as the bytes 1b 5b 3f 31 30 33 34 68. The exact value
> of the escape sequence is configurable and may be found on a GNU/Linux
> platform by running the command:
> {code:java}
> tput smm | hexdump{code}
> If this command gives no output, then the set meta mode sequence is not
> defined on this platform for the terminal in use. Refer to the xterm and
> terminfo man pages for more information on this sequence.
> There are easier ways to solve this problem for the sake of the unit test,
> but if time allows, I'd like to look into this to achieve a more consistent
> output behavior for cqlsh on GNU/Linux platforms.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14494) Investigate possibility of a cqlsh terminfo
[
https://issues.apache.org/jira/browse/CASSANDRA-14494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Bannister reassigned CASSANDRA-14494:
-
Assignee: Patrick Bannister
> Investigate possibility of a cqlsh terminfo
> ---
>
> Key: CASSANDRA-14494
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14494
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/Tools
> Environment: This behavior has been observed in xterm on CentOS 7.5
> platforms. The test_cqlsh_output.py unit tests
> (pylib/cqlshlib/test/test_cqlsh_output.py) are a good place to see it in
> action.
>Reporter: Patrick Bannister
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: Python, cqlsh, test
> Fix For: 4.x
>
>
> Summary: investigate whether we could use a cqlsh-specific terminfo file to
> prevent use of the set-meta-mode escape sequence in xterm without breaking
> colors. If it works, see if we can install it in an appropriate place using
> Python distutils. If yes to both, generate a cqlsh terminfo file and work it
> into the install process.
> Long detailed explanation:
> In some more recent environments, in Python REPL applications that use the
> readline module, the set meta mode escape sequence is output before each
> prompt. This escape sequence has caused problems for some applications, and
> in our case, some of our cqlsh unit tests
> (pylib/cqlshlib/test/test_cqlsh_output.py) choke on this output because of
> the way our tests are designed to detect the cqlsh prompt. This behavior was
> observed on a CentOS 7.5 platform.
> The set-meta-mode escape sequence normally appears as "[?1034h" in output;
> it's normally defined as the bytes 1b 5b 3f 31 30 33 34 68. The exact value
> of the escape sequence is configurable and may be found on a GNU/Linux
> platform by running the command:
> {code:java}
> tput smm | hexdump{code}
> If this command gives no output, then the set meta mode sequence is not
> defined on this platform for the terminal in use. Refer to the xterm and
> terminfo man pages for more information on this sequence.
> There are easier ways to solve this problem for the sake of the unit test,
> but if time allows, I'd like to look into this to achieve a more consistent
> output behavior for cqlsh on GNU/Linux platforms.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841844#comment-16841844 ] Patrick Bannister commented on CASSANDRA-10190: --- [~spo...@gmail.com], this has been progressing, and we'd like your review and feedback. I have a branch from cassandra trunk that will make cqlsh, cqlshlib, and the accompanying Python unit tests work for Python 2.7 and 3.6: https://github.com/ptbannister/cassandra/tree/10190-rebase-20190329 If the cqlsh and cqlshlib changes are good, then we'd circle back to update the dtests too, but in a separate PR. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16833198#comment-16833198 ] Patrick Bannister commented on CASSANDRA-10190: --- In the cqlshlib tests, in test_cqlsh_output.py, test_user_types_output is failing on Python 3. This is because of an unhandled exception in the cassandra Python driver. This is happening because of the Python 3 behavior of throwing an exception when a str type object is compared to a NoneType object (which was not a problem in Python 2). The test data includes a user defined type that is populated with some null fields, and when the Cassandra driver tries to output this data, it does some comparison, and this causes an exception, which it does not handle. We will need to accept this as a known failure until we can address the behavior in the driver. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805180#comment-16805180 ] Patrick Bannister commented on CASSANDRA-10190: --- Update on the tests: I have everything passing, except for some problems that appear rooted in the driver: * cassandra-dtest cqlsh_tests/test_cqlsh_copy.py TestCqlshCopy test_unusual_dates: the driver is choking when it tries to read dates after the year 1. * cqlshlib tests pylib/cqlshlib/test/test_cqlsh_output.py TestCqlshOutput test_user_types_output: the driver is choking when it tries to read a user defined type for a frozen set with nulls. Python does not support ordering a collection with null values (NoneType). I don't believe either of these problems can be solved with cqlshlib alone. Probably we would need to contribute to the driver to resolve them. My feeling is that both of these problems are blockers. Any input from our watchers? > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805175#comment-16805175 ] Patrick Bannister commented on CASSANDRA-10190: --- It's difficult to provide an ETA. This is a big ticket, and most of us are working on a volunteer basis. The best I can say is that I've heard there's a lot of interest in this ticket, and that should provide some motivation to get it done. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14990) Move cqlsh tests to dtest repo
[ https://issues.apache.org/jira/browse/CASSANDRA-14990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804996#comment-16804996 ] Patrick Bannister commented on CASSANDRA-14990: --- [~djoshi3], some of the cqlshlib test files are nothing but stubs. Why don't we remove them? * pylib/cqlshlib/tests/test_cqlsh_commands.py * pylib/cqlshlib/tests/test_cqlsh_invocation.py * pylib/cqlshlib/tests/test_cqlsh_parsing.py > Move cqlsh tests to dtest repo > -- > > Key: CASSANDRA-14990 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14990 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest, Tool/cqlsh >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Low > > The cqlsh tests are split into the dtest repo and the main Cassandra repo. We > should move them to dtests repo and migrate them from nosetests to pytests. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804977#comment-16804977 ] Patrick Bannister commented on CASSANDRA-10190: --- [~djoshi3] is working on moving the cqlshlib tests to the dtests in CASSANDRA-14990. On his suggestion, I'll build on his work. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804971#comment-16804971 ] Patrick Bannister commented on CASSANDRA-10190: --- All of the cqlsh_tests dtests are passing again, time to look at the cqlshlib tests. Now we need to revisit the cqlshlib tests. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799483#comment-16799483 ] Patrick Bannister commented on CASSANDRA-10190: --- CASSANDRA-14298 has been merged, and I've resumed work on this ticket. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister reassigned CASSANDRA-10190: - Assignee: Patrick Bannister > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: CASSANDRA-14298-blogposts-and-ratefile-workarounds.txt > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest, pull-request-available > Attachments: CASSANDRA-14298-blogposts-and-ratefile-workarounds.txt, > CASSANDRA-14298.txt, cqlsh_tests_notes.md > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782253#comment-16782253 ] Patrick Bannister commented on CASSANDRA-14298: --- I've posted a new patch with some possible workarounds for the test_bulk_round_trip_blogposts* and test_round_trip_with_ratefile failures. For the blogposts tests, I added a retry policy to the select count statement. For the ratefile test, I increased the number of rows written with stress, to make sure the stress tool writes for at least one second. I can't reproduce any of these failures on the environments I've tried, even running the tests inside the same Docker container used by CircleCI. But hopefully these workarounds will address these problems. I'm not sure what's going on with the failures in the test teardowns. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest, pull-request-available > Attachments: CASSANDRA-14298.txt, cqlsh_tests_notes.md > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16781710#comment-16781710 ] Patrick Bannister commented on CASSANDRA-14298: --- The failures in test_bulk_round_trip_blogposts* are happening when we do a SELECT COUNT statement by executing a Cassandra driver SimpleStatement with ConsistencyLevel.ALL. It can't achieve the desired consistency level for some reason. I have some ideas for how to work around the problem - either a retry strategy, or else I'll execute that statement with a ccm run_cqlsh call instead. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest, pull-request-available > Attachments: CASSANDRA-14298.txt, cqlsh_tests_notes.md > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16780067#comment-16780067 ] Patrick Bannister commented on CASSANDRA-14298: --- Here's what I think I see: * In container #26, test_cqlsh.py passes * In container #28, test_cqlsh_copy.py test_bulk_round_trip_blogposts fails because some of the nodes of the ccm cluster wouldn't start * In container #29, test_cqlsh_copy.py test_bulk_round_trip_blogposts_with_max_connections fails because the ccm cluster has problems with its virtual network * In container #68, test_cqlsh_copy.py test_round_trip_with_rate_file fails because expected and observed data don't match. This may be another environmental resource issue - I think we get trouble when the environment is too slammed to get data through at the desired rate These tests pass for me when I run the cqlsh copy tests in isolation. I'm thinking about breaking the resource intensive bulk round trip tests in the cqlsh copy tests into a separate script, and marking them as resource intensive. What options does our test infrastructure offer for dealing with resource intensive tests? I know [~spo...@gmail.com] had some long term plans to improve the infrax to deal with this, but maybe we have some options right now that we could exercise by restructuring the cqlsh tests a bit. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest, pull-request-available > Attachments: CASSANDRA-14298.txt, cqlsh_tests_notes.md > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16778833#comment-16778833 ] Patrick Bannister commented on CASSANDRA-10190: --- I think I'll need to look at this more closely to understand what happened, but sharing my initial intuition: I suspect this is a change in the internals of the Python re module. The saferscanner class plays with fire by extending the Python re.Scanner class. Scanner is supposed to be internal, not a public API offering, and dealing with changes in re.Scanner between Python 2.7 and Python 3 was one of the first challenges I tackled in porting cqlsh to Python 3. That's just my gut feeling looking at the stacktrace. I can look more in depth after I do more work with this branch when CASSANDRA-14298 is merged. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777291#comment-16777291 ] Patrick Bannister commented on CASSANDRA-10190: --- Please check out my branches for this on Github: * [https://github.com/ptbannister/cassandra.git] * [https://github.com/ptbannister/cassandra-dtest.git] * [https://github.com/ptbannister/ccm.git] On one line of work I was working in straight Python 3, no Python 2.7 compatibility. For that one, check out the cassandra and cassandra-dtest branches called "cqlshlib3". But I built on that to make it compatible with both Python 3 and Python 2.7. I was working on that branch later, so I have a bit more confidence in it. For that one, check out the branches called "cqlshlib6." This also requires a small change to ccm, which is available in the cqlshlib6 branch of my ccm fork. Caveat that I haven't looked at this since October, so there may be some problems running it now unless you use a Cassandra Python driver from around that time. I've been planning to pick this back up and finish it after CASSANDRA-14298 gets merged. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774002#comment-16774002 ] Patrick Bannister commented on CASSANDRA-10190: --- We've resumed CASSANDRA-14298 in the past week, hopefully we'll get that done soon, and that would clear the way for this ticket. I had a patch that got cqlsh working on 3 and 2.7 in October. The saferscanner problems are solvable. Patrick Bannister > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: CASSANDRA-14298.txt > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298.txt, cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Status: Patch Available (was: In Progress) Attachment CASSANDRA-14298.txt is a new patch for the head of cassandra-dtest master (currently commit e6f58cb33f7a09f273c5990d5d21c7b529ba80bf). As previously discussed on this ticket, this patch deselects 27 tests in test_cqlsh_copy.py that depend on importing the Python 2.7 cqlshlib into the Python 3 dtests, and gets the remaining tests to pass. I've gotten passing tests with this patch on AWS t2.large instances running Ubuntu and CentOS 7 with trunk, cassandra-3.11, and cassandra-3.0. The environment must have the en_US.UTF-8 locale generated, with the environment variable LC_CTYPE=en_US.UTF-8. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298.txt, cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770270#comment-16770270 ] Patrick Bannister commented on CASSANDRA-14298: --- I'm finalizing a new patch. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: (was: CASSANDRA-14298.txt) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: (was: CASSANDRA-14298-old.txt) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Legacy/Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-13047: -- Attachment: (was: 13047-3.11.txt) > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Major > Fix For: 4.0 > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-13047: -- Status: Open (was: Patch Available) Looking at this in light of CASSANDRA-13047. Currently we have two versions of the docs: 3.11 for 3.11 and older, latest for 4.0. I anticipate the versions will be a moving target going forward. I'm thinking the answer to this is to have the versioned docs website redirect requests for all version numbers to the appropriate versioned docs for that version number. > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Major > Fix For: 4.0 > > Attachments: 13047-3.11.txt > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16612850#comment-16612850 ] Patrick Bannister commented on CASSANDRA-14298: --- I attached [https://github.com/mkjellman/cassandra-test-docker/blob/master/Dockerfile] to CASSANDRA-14713. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14713) Add docker testing image to cassandra-builds
[
https://issues.apache.org/jira/browse/CASSANDRA-14713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Bannister updated CASSANDRA-14713:
--
Attachment: Dockerfile
> Add docker testing image to cassandra-builds
>
>
> Key: CASSANDRA-14713
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14713
> Project: Cassandra
> Issue Type: New Feature
> Components: Testing
>Reporter: Stefan Podkowinski
>Priority: Major
> Attachments: Dockerfile
>
>
> Tests executed on builds.apache.org ({{docker/jenkins/jenkinscommand.sh}})
> and circleCI ({{.circleci/config.yml}}) will currently use the same
> [cassandra-test|https://hub.docker.com/r/kjellman/cassandra-test/] docker
> image ([github|https://github.com/mkjellman/cassandra-test-docker]) by
> [~mkjellman].
> We should manage this image on our own as part of cassandra-builds, to keep
> it updated. There's also a [Apache
> user|https://hub.docker.com/u/apache/?page=1] on docker hub for publishing
> images.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16592916#comment-16592916 ] Patrick Bannister commented on CASSANDRA-10190: --- Quick update on this ticket. The porting work is mostly done - I had basically all the tests passing under Python 2.7 and Python 3.5 on CentOS and Ubuntu environments. Making the dtests Python 2/3 cross compatible was trivial, mostly I just had to add explicit inheritance from the object class to a few of the basic classes like dtest.py. There will be a small patch to ccm related to Unicode encoding when calling cqlsh. I've learned a bit about our test infrastructure, so I have a better idea of what will be involved for the testing environment subtask (CASSANDRA-14491). I'll continue work on this ticket after we complete CASSANDRA-14298 - that task is building momentum again so I think it will be soon. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16592393#comment-16592393 ] Patrick Bannister commented on CASSANDRA-14298: --- Posted a new patch (CASSANDRA-14298.txt) that fixes the failures in test_unicode_invalid_request_error and test_materialized_view. test_pycodestyle_compliance is still failing, because it's complaining about Python style in cqlsh and cqlshlib, which is out of scope for this ticket. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: CASSANDRA-14298.txt > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: (was: CASSANDRA-14298.txt) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[
https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590988#comment-16590988
]
Patrick Bannister commented on CASSANDRA-14298:
---
[~spo...@gmail.com], I diagnosed the cause of the Unicode related failures. You
are running the dtests in the Docker image kjellman/cassandra-test:0.4.4. That
image does not have a locale configured, other than C.UTF-8.
I recommend we resolve this by adding the following RUN command to the
Dockerfile and rebuilding the image:
{code:java}
RUN sudo apt-get -q -y install locales && sudo locale-gen en_US.UTF-8 && sudo
apt-get -q -y remove locales
{code}
I still need to look into the other failures you encountered, but this should
at least clear up the Unicode problems.
> cqlshlib tests broken on b.a.o
> --
>
> Key: CASSANDRA-14298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14298
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Testing
>Reporter: Stefan Podkowinski
>Assignee: Patrick Bannister
>Priority: Major
> Labels: cqlsh, dtest
> Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt,
> cqlsh_tests_notes.md
>
>
> It appears that cqlsh-tests on builds.apache.org on all branches stopped
> working since we removed nosetests from the system environment. See e.g.
> [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console].
> Looks like we either have to make nosetests available again or migrate to
> pytest as we did with dtests. Giving pytest a quick try resulted in many
> errors locally, but I haven't inspected them in detail yet.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590125#comment-16590125 ] Patrick Bannister commented on CASSANDRA-14298: --- [~spo...@gmail.com], I'm working on duplicating your test environment to troubleshoot the problems you mentioned. Those problems don't arise on my simpler Ubuntu and Centos environments, so I suspect it's something related to setting up the cassandra-builds dtest environment. Is it possible to run the test script (```/cassandra-builds/docker/jenkins/jenkinscommand.sh apache trunk https://github.com/spodkowinski/cassandra-dtest.git CASSANDRA-14298 https://git.apache.org/cassandra-builds.git master```) outside of builds.apache.org or some other specifically configured Jenkins server? > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580629#comment-16580629 ] Patrick Bannister commented on CASSANDRA-14298: --- [~spo...@gmail.com], I built a CentOS system, checked out your copy of CASSANDRA-14298, and ran some of the tests that failed on build 597. I have LANG=en_US.utf8 and nothing set for LC_ALL or LC_CTYPE. Almost all of the Unicode related tests passed: * test_eat_glass * test_source_glass * test_unicode_syntax_error * test_with_empty_values * test_copy_to I have two suggestions: * Please check the output of locale -a on your test system and confirm that you have an en_US.utf8 locale generated. * If locale -a lists en_US.utf8 but not en_US.UTF-8, please try setting the environment variable LANG=en_US.utf8. Alternatively - is it possible for me to duplicate your Jenkins build and do that troubleshooting myself? I haven't set up on Jenkins yet, but I'd be willing to do it to work more efficiently on this ticket and eat up a little less of your time. Other failures...test_unicode_invalid_request_error fails for me too, but it looks like a superficial problem. test_materialized_view looks like a more substantive issue. I'll check into both. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568986#comment-16568986 ] Patrick Bannister commented on CASSANDRA-14298: --- [~spo...@gmail.com], great to hear from you again. I'll start looking into this. I've been on a break for a couple of weeks, and coming back to it now, I can't get ccm to start - I get the error "[node1 ERROR] b'Error: Could not find or load main class org.apache.cassandra.service.CassandraDaemon'." Did we add a new dependency or something? > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13907) Versioned documentation on cassandra.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16535293#comment-16535293 ] Patrick Bannister commented on CASSANDRA-13907: --- How are things going with versioned documentation? Over on CASSANDRA-13047 we're looking at updating cqlsh to point to online help; currently it points to dead links for an older version of the docs. We could easily update cqlsh to point to the currently available online help, but depending on your expected timeline, it might make more sense to hold out for versioned docs. > Versioned documentation on cassandra.apache.org > --- > > Key: CASSANDRA-13907 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13907 > Project: Cassandra > Issue Type: Improvement > Components: Documentation and Website >Reporter: Murukesh Mohanan >Priority: Minor > > Services like https://readthedocs.org and http://www.javadoc.io/ make it easy > to browse the documentation for a particular version or commit of various > open source projects. It would be nice to be able to browse the docs for a > particular release on http://cassandra.apache.org/doc/. > Currently it seems only CQL has this at http://cassandra.apache.org/doc/old/. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16535289#comment-16535289 ] Patrick Bannister commented on CASSANDRA-13047: --- Let's get an status update on CASSANDRA-13907. > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Major > Fix For: 4.0 > > Attachments: 13047-3.11.txt > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16534374#comment-16534374 ] Patrick Bannister commented on CASSANDRA-13047: --- [~nmschorr], yes, it sounds like you're experiencing the bug addressed by this ticket. > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: CQL >Reporter: Sylvain Lebresne >Assignee: Patrick Bannister >Priority: Major > Fix For: 4.0 > > Attachments: 13047-3.11.txt > > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14493) Test describe statements for aggregates, functions, indexes, schemas, types, and user types
[ https://issues.apache.org/jira/browse/CASSANDRA-14493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister resolved CASSANDRA-14493. --- Resolution: Implemented Demonstrated existing coverage for describing indexes and schemas, and added new tests for describing functions, aggregates, and user defined types. > Test describe statements for aggregates, functions, indexes, schemas, types, > and user types > --- > > Key: CASSANDRA-14493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14493 > Project: Cassandra > Issue Type: Sub-task >Reporter: Patrick Bannister >Priority: Major > Fix For: 4.x > > > Coverage analysis of the cqlsh unittests (pylib/cqlshlib/test/test*.py) and > the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no > coverage of functions for describing aggregates, functions, indexes, schemas, > types, or usertypes. > Before we can release a ported cqlsh, we should either create a new test that > exercises these kinds of describe statements, or refute the coverage report > by identifying an existing test for these features. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14493) Test describe statements for aggregates, functions, indexes, schemas, types, and user types
[ https://issues.apache.org/jira/browse/CASSANDRA-14493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529272#comment-16529272 ] Patrick Bannister commented on CASSANDRA-14493: --- Added a new test for DESCRIBE TYPE. > Test describe statements for aggregates, functions, indexes, schemas, types, > and user types > --- > > Key: CASSANDRA-14493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14493 > Project: Cassandra > Issue Type: Sub-task >Reporter: Patrick Bannister >Priority: Major > Fix For: 4.x > > > Coverage analysis of the cqlsh unittests (pylib/cqlshlib/test/test*.py) and > the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no > coverage of functions for describing aggregates, functions, indexes, schemas, > types, or usertypes. > Before we can release a ported cqlsh, we should either create a new test that > exercises these kinds of describe statements, or refute the coverage report > by identifying an existing test for these features. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14493) Test describe statements for aggregates, functions, indexes, schemas, types, and user types
[ https://issues.apache.org/jira/browse/CASSANDRA-14493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16529125#comment-16529125 ] Patrick Bannister commented on CASSANDRA-14493: --- DESCRIBE AGGREGATE and DESCRIBE FUNCTION are done. DESCRIBE for user defined types is next on my list. > Test describe statements for aggregates, functions, indexes, schemas, types, > and user types > --- > > Key: CASSANDRA-14493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14493 > Project: Cassandra > Issue Type: Sub-task >Reporter: Patrick Bannister >Priority: Major > Fix For: 4.x > > > Coverage analysis of the cqlsh unittests (pylib/cqlshlib/test/test*.py) and > the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no > coverage of functions for describing aggregates, functions, indexes, schemas, > types, or usertypes. > Before we can release a ported cqlsh, we should either create a new test that > exercises these kinds of describe statements, or refute the coverage report > by identifying an existing test for these features. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14493) Test describe statements for aggregates, functions, indexes, schemas, types, and user types
[ https://issues.apache.org/jira/browse/CASSANDRA-14493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16528961#comment-16528961 ] Patrick Bannister commented on CASSANDRA-14493: --- We already have tests that cover DESCRIBE statements for indexes and schemas (in the test_describe dtest in cassandra-dtest cqlsh_tests/cqlsh_tests.py). Coverage analysis shows we're exercising those functions after fixing flakiness in test_describe. Also, a "usertype" is not a separate thing from a "type" in the context of DESCRIBE statements, so no separate testing will be needed for describing types vs. describing usertypes. We still need additional testing to exercise describing aggregates, functions, and (user defined) types. > Test describe statements for aggregates, functions, indexes, schemas, types, > and user types > --- > > Key: CASSANDRA-14493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14493 > Project: Cassandra > Issue Type: Sub-task >Reporter: Patrick Bannister >Priority: Major > Fix For: 4.x > > > Coverage analysis of the cqlsh unittests (pylib/cqlshlib/test/test*.py) and > the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no > coverage of functions for describing aggregates, functions, indexes, schemas, > types, or usertypes. > Before we can release a ported cqlsh, we should either create a new test that > exercises these kinds of describe statements, or refute the coverage report > by identifying an existing test for these features. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14490) Test displaying CJK languages
[ https://issues.apache.org/jira/browse/CASSANDRA-14490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister resolved CASSANDRA-14490. --- Resolution: Not A Problem The unused CJK related functions of wcwidth are not necessary for displaying CJK text in Unicode. > Test displaying CJK languages > - > > Key: CASSANDRA-14490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14490 > Project: Cassandra > Issue Type: Sub-task >Reporter: Patrick Bannister >Priority: Major > Labels: cqlsh, test > Fix For: 4.0.x > > > Coverage analysis of cqlsh tests showed no coverage of wcwidth functions > related to displaying CJK languages. Before releasing a port, we should > identify or create a test that exercises code paths for displaying CJK > language data in cqlsh. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14490) Test displaying CJK languages
[ https://issues.apache.org/jira/browse/CASSANDRA-14490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16528939#comment-16528939 ] Patrick Bannister commented on CASSANDRA-14490: --- Looking at this closer: there is actually nothing in cqlsh that can use the cjk specific functions of wcwidth. Furthermore, those functions are only intended to support users who want to migrate to Unicode from a legacy CJK encoding. Nevertheless, I've added test_cjk_output to TestCqlshSmoke in cqlsh_tests/cqlsh_tests.py in the developmental branch for the port. > Test displaying CJK languages > - > > Key: CASSANDRA-14490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14490 > Project: Cassandra > Issue Type: Sub-task >Reporter: Patrick Bannister >Priority: Major > Labels: cqlsh, test > Fix For: 4.0.x > > > Coverage analysis of cqlsh tests showed no coverage of wcwidth functions > related to displaying CJK languages. Before releasing a port, we should > identify or create a test that exercises code paths for displaying CJK > language data in cqlsh. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14492) Test use of thousands separators and comma decimal separators
[
https://issues.apache.org/jira/browse/CASSANDRA-14492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Bannister resolved CASSANDRA-14492.
---
Resolution: Not A Problem
Confirmed that test_number_separators_round_trip() in dtests
cqlsh_tests/cqlsh_copy_tests.py already tests these features.
> Test use of thousands separators and comma decimal separators
> -
>
> Key: CASSANDRA-14492
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14492
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Patrick Bannister
>Priority: Major
> Labels: cqlsh, test
> Fix For: 4.x
>
>
> Coverage analysis showed no coverage for functions related to displaying
> numbers with thousands separators ("$100,000,000,000" instead of
> "$1000") and displaying numbers with custom decimal separators
> ("3,1415927" instead of "3.1415927").
> We should add a test that displays numbers like this, or identify an existing
> test that does it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14492) Test use of thousands separators and comma decimal separators
[
https://issues.apache.org/jira/browse/CASSANDRA-14492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527071#comment-16527071
]
Patrick Bannister commented on CASSANDRA-14492:
---
Looks like my original coverage analysis didn't handle termination of the
multiprocessing.Process objects that we run to do COPY tasks. After resolving
this, it's clear that we are definitely exercising the codepaths for custom
thousands separators and decimal separators.
> Test use of thousands separators and comma decimal separators
> -
>
> Key: CASSANDRA-14492
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14492
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Patrick Bannister
>Priority: Major
> Labels: cqlsh, test
> Fix For: 4.x
>
>
> Coverage analysis showed no coverage for functions related to displaying
> numbers with thousands separators ("$100,000,000,000" instead of
> "$1000") and displaying numbers with custom decimal separators
> ("3,1415927" instead of "3.1415927").
> We should add a test that displays numbers like this, or identify an existing
> test that does it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14492) Test use of thousands separators and comma decimal separators
[
https://issues.apache.org/jira/browse/CASSANDRA-14492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525752#comment-16525752
]
Patrick Bannister edited comment on CASSANDRA-14492 at 6/28/18 2:10 AM:
The dtest test_number_separators_round_trip() in
cqlsh_tests/cqlsh_copy_tests.py already tests both of these features. Looking
further into why initial coverage analysis didn't catch that.
was (Author: ptbannister):
The dtest test_number_separators_round_trip() in
cqlsh_tests/cqlsh_copy_tests.py already tests both of these features. However,
since the test occurs in the context of COPY statements, it uses a different
code path: there's a separate integer formatting function used for COPY TO
statements, implemented in cqlshlib/copyutil.py, instead of the formatting
functions in cqlshlib/formatting.py.
It's interesting that we've implemented datatype formatting in more than one
place.
> Test use of thousands separators and comma decimal separators
> -
>
> Key: CASSANDRA-14492
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14492
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Patrick Bannister
>Priority: Major
> Labels: cqlsh, test
> Fix For: 4.x
>
>
> Coverage analysis showed no coverage for functions related to displaying
> numbers with thousands separators ("$100,000,000,000" instead of
> "$1000") and displaying numbers with custom decimal separators
> ("3,1415927" instead of "3.1415927").
> We should add a test that displays numbers like this, or identify an existing
> test that does it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14492) Test use of thousands separators and comma decimal separators
[
https://issues.apache.org/jira/browse/CASSANDRA-14492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525752#comment-16525752
]
Patrick Bannister commented on CASSANDRA-14492:
---
The dtest test_number_separators_round_trip() in
cqlsh_tests/cqlsh_copy_tests.py already tests both of these features. However,
since the test occurs in the context of COPY statements, it uses a different
code path: there's a separate integer formatting function used for COPY TO
statements, implemented in cqlshlib/copyutil.py, instead of the formatting
functions in cqlshlib/formatting.py.
It's interesting that we've implemented datatype formatting in more than one
place.
> Test use of thousands separators and comma decimal separators
> -
>
> Key: CASSANDRA-14492
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14492
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Patrick Bannister
>Priority: Major
> Labels: cqlsh, test
> Fix For: 4.x
>
>
> Coverage analysis showed no coverage for functions related to displaying
> numbers with thousands separators ("$100,000,000,000" instead of
> "$1000") and displaying numbers with custom decimal separators
> ("3,1415927" instead of "3.1415927").
> We should add a test that displays numbers like this, or identify an existing
> test that does it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14534) cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525500#comment-16525500
]
Patrick Bannister commented on CASSANDRA-14534:
---
This test is working now in development for CASSANDRA-10190.
> cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
> -
>
> Key: CASSANDRA-14534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14534
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
> Environment: trunk running on Ubuntu 16.04 LTS
>Reporter: Patrick Bannister
>Priority: Minor
> Labels: cqlsh, dtest, flaky-test, test
> Fix For: 4.x
>
>
> *Summary:* test_describe in cqlsh_tests/cqlsh_tests.py::TestCqlsh is flaky.
> The test is written to expect the objects of a keyspace to be
> lexicographically sorted in DESCRIBE KEYSPACE output. However, this almost
> never happens, because the sort order of objects in DESCRIBE KEYSPACE output
> is arbitrary. I plan to modify the test to check for expected output without
> requiring lexicographic sorting of items of the same type; this work would be
> rolled up under other work in CASSANDRA-10190.
> This is happening in the Cassandra Python driver, in cassandra.metadata, in
> the KeyspaceMetadata and TableMetadata classes. KeyspaceMetadata and
> TableMetadata store their child objects in Python dictionaries, and when
> generating DESCRIBE output, they visit their child objects in the order
> returned by the values() function of each dictionary. The Python dictionary
> values() function returns items in an arbitrary order, so they will not
> necessarily come back sorted lexicographically as expected by the test.
> A simple fix for the test would be to change the way it checks for the
> expected output so that the order of objects of the same type is no longer
> important.
> As currently written, the test creates a keyspace like so:
>
> {code:java}
> CREATE KEYSPACE test WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE test.users ( userid text PRIMARY KEY, firstname text, lastname
> text, age int);
> CREATE INDEX myindex ON test.users (age);
> CREATE INDEX "QuotedNameIndex" on test.users (firstName);
> CREATE TABLE test.test (id int, col int, val text, PRIMARY KEY(id, col));
> CREATE INDEX ON test.test (col);
> CREATE INDEX ON test.test (val){code}
>
> It expects the output of DESCRIBE KEYSPACE test to appear in the following
> order:
>
> {code:java}
> CREATE KEYSPACE test...
> CREATE TABLE test.test...
> CREATE INDEX test_col_idx...
> CREATE INDEX test_val_idx...
> CREATE TABLE test.users...
> CREATE INDEX "QuotedNameIndex"...
> CREATE INDEX myindex...{code}
> But as described above, tables aren't sorted lexicographically, and a table's
> indexes aren't sorted lexicographically, so output for table test.users can
> come before output for table test.test, and output for index test_val_idx can
> come before output for index test_col_idx. The planned change to the test
> would make it so that the test passes regardless of the order of these like
> objects.
> If lexicographic sorting of objects of like type actually is a requirement
> for DESCRIBE KEYSPACE, then we could fix this by modifying cqlsh
> (duplicative, but simple), or by modifying the Cassandra Python driver's
> cassandra/metadata.py script file (less duplicative but more difficult to
> distribute).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14534) cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Bannister resolved CASSANDRA-14534.
---
Resolution: Implemented
> cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
> -
>
> Key: CASSANDRA-14534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14534
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
> Environment: trunk running on Ubuntu 16.04 LTS
>Reporter: Patrick Bannister
>Priority: Minor
> Labels: cqlsh, dtest, flaky-test, test
> Fix For: 4.x
>
>
> *Summary:* test_describe in cqlsh_tests/cqlsh_tests.py::TestCqlsh is flaky.
> The test is written to expect the objects of a keyspace to be
> lexicographically sorted in DESCRIBE KEYSPACE output. However, this almost
> never happens, because the sort order of objects in DESCRIBE KEYSPACE output
> is arbitrary. I plan to modify the test to check for expected output without
> requiring lexicographic sorting of items of the same type; this work would be
> rolled up under other work in CASSANDRA-10190.
> This is happening in the Cassandra Python driver, in cassandra.metadata, in
> the KeyspaceMetadata and TableMetadata classes. KeyspaceMetadata and
> TableMetadata store their child objects in Python dictionaries, and when
> generating DESCRIBE output, they visit their child objects in the order
> returned by the values() function of each dictionary. The Python dictionary
> values() function returns items in an arbitrary order, so they will not
> necessarily come back sorted lexicographically as expected by the test.
> A simple fix for the test would be to change the way it checks for the
> expected output so that the order of objects of the same type is no longer
> important.
> As currently written, the test creates a keyspace like so:
>
> {code:java}
> CREATE KEYSPACE test WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE test.users ( userid text PRIMARY KEY, firstname text, lastname
> text, age int);
> CREATE INDEX myindex ON test.users (age);
> CREATE INDEX "QuotedNameIndex" on test.users (firstName);
> CREATE TABLE test.test (id int, col int, val text, PRIMARY KEY(id, col));
> CREATE INDEX ON test.test (col);
> CREATE INDEX ON test.test (val){code}
>
> It expects the output of DESCRIBE KEYSPACE test to appear in the following
> order:
>
> {code:java}
> CREATE KEYSPACE test...
> CREATE TABLE test.test...
> CREATE INDEX test_col_idx...
> CREATE INDEX test_val_idx...
> CREATE TABLE test.users...
> CREATE INDEX "QuotedNameIndex"...
> CREATE INDEX myindex...{code}
> But as described above, tables aren't sorted lexicographically, and a table's
> indexes aren't sorted lexicographically, so output for table test.users can
> come before output for table test.test, and output for index test_val_idx can
> come before output for index test_col_idx. The planned change to the test
> would make it so that the test passes regardless of the order of these like
> objects.
> If lexicographic sorting of objects of like type actually is a requirement
> for DESCRIBE KEYSPACE, then we could fix this by modifying cqlsh
> (duplicative, but simple), or by modifying the Cassandra Python driver's
> cassandra/metadata.py script file (less duplicative but more difficult to
> distribute).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14534) cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Bannister updated CASSANDRA-14534:
--
Issue Type: Sub-task (was: Test)
Parent: CASSANDRA-10190
> cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
> -
>
> Key: CASSANDRA-14534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14534
> Project: Cassandra
> Issue Type: Sub-task
> Components: CQL
> Environment: trunk running on Ubuntu 16.04 LTS
>Reporter: Patrick Bannister
>Priority: Minor
> Labels: cqlsh, dtest, flaky-test, test
> Fix For: 4.x
>
>
> *Summary:* test_describe in cqlsh_tests/cqlsh_tests.py::TestCqlsh is flaky.
> The test is written to expect the objects of a keyspace to be
> lexicographically sorted in DESCRIBE KEYSPACE output. However, this almost
> never happens, because the sort order of objects in DESCRIBE KEYSPACE output
> is arbitrary. I plan to modify the test to check for expected output without
> requiring lexicographic sorting of items of the same type; this work would be
> rolled up under other work in CASSANDRA-10190.
> This is happening in the Cassandra Python driver, in cassandra.metadata, in
> the KeyspaceMetadata and TableMetadata classes. KeyspaceMetadata and
> TableMetadata store their child objects in Python dictionaries, and when
> generating DESCRIBE output, they visit their child objects in the order
> returned by the values() function of each dictionary. The Python dictionary
> values() function returns items in an arbitrary order, so they will not
> necessarily come back sorted lexicographically as expected by the test.
> A simple fix for the test would be to change the way it checks for the
> expected output so that the order of objects of the same type is no longer
> important.
> As currently written, the test creates a keyspace like so:
>
> {code:java}
> CREATE KEYSPACE test WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE test.users ( userid text PRIMARY KEY, firstname text, lastname
> text, age int);
> CREATE INDEX myindex ON test.users (age);
> CREATE INDEX "QuotedNameIndex" on test.users (firstName);
> CREATE TABLE test.test (id int, col int, val text, PRIMARY KEY(id, col));
> CREATE INDEX ON test.test (col);
> CREATE INDEX ON test.test (val){code}
>
> It expects the output of DESCRIBE KEYSPACE test to appear in the following
> order:
>
> {code:java}
> CREATE KEYSPACE test...
> CREATE TABLE test.test...
> CREATE INDEX test_col_idx...
> CREATE INDEX test_val_idx...
> CREATE TABLE test.users...
> CREATE INDEX "QuotedNameIndex"...
> CREATE INDEX myindex...{code}
> But as described above, tables aren't sorted lexicographically, and a table's
> indexes aren't sorted lexicographically, so output for table test.users can
> come before output for table test.test, and output for index test_val_idx can
> come before output for index test_col_idx. The planned change to the test
> would make it so that the test passes regardless of the order of these like
> objects.
> If lexicographic sorting of objects of like type actually is a requirement
> for DESCRIBE KEYSPACE, then we could fix this by modifying cqlsh
> (duplicative, but simple), or by modifying the Cassandra Python driver's
> cassandra/metadata.py script file (less duplicative but more difficult to
> distribute).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14534) cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518737#comment-16518737
]
Patrick Bannister commented on CASSANDRA-14534:
---
Work for this issue would probably be submitted with the dtests patch in
development for CASSANDRA-10190.
> cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
> -
>
> Key: CASSANDRA-14534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14534
> Project: Cassandra
> Issue Type: Test
> Components: CQL
> Environment: trunk running on Ubuntu 16.04 LTS
>Reporter: Patrick Bannister
>Priority: Minor
> Labels: cqlsh, dtest, flaky-test, test
> Fix For: 4.x
>
>
> *Summary:* test_describe in cqlsh_tests/cqlsh_tests.py::TestCqlsh is flaky.
> The test is written to expect the objects of a keyspace to be
> lexicographically sorted in DESCRIBE KEYSPACE output. However, this almost
> never happens, because the sort order of objects in DESCRIBE KEYSPACE output
> is arbitrary. I plan to modify the test to check for expected output without
> requiring lexicographic sorting of items of the same type; this work would be
> rolled up under other work in CASSANDRA-10190.
> This is happening in the Cassandra Python driver, in cassandra.metadata, in
> the KeyspaceMetadata and TableMetadata classes. KeyspaceMetadata and
> TableMetadata store their child objects in Python dictionaries, and when
> generating DESCRIBE output, they visit their child objects in the order
> returned by the values() function of each dictionary. The Python dictionary
> values() function returns items in an arbitrary order, so they will not
> necessarily come back sorted lexicographically as expected by the test.
> A simple fix for the test would be to change the way it checks for the
> expected output so that the order of objects of the same type is no longer
> important.
> As currently written, the test creates a keyspace like so:
>
> {code:java}
> CREATE KEYSPACE test WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE test.users ( userid text PRIMARY KEY, firstname text, lastname
> text, age int);
> CREATE INDEX myindex ON test.users (age);
> CREATE INDEX "QuotedNameIndex" on test.users (firstName);
> CREATE TABLE test.test (id int, col int, val text, PRIMARY KEY(id, col));
> CREATE INDEX ON test.test (col);
> CREATE INDEX ON test.test (val){code}
>
> It expects the output of DESCRIBE KEYSPACE test to appear in the following
> order:
>
> {code:java}
> CREATE KEYSPACE test...
> CREATE TABLE test.test...
> CREATE INDEX test_col_idx...
> CREATE INDEX test_val_idx...
> CREATE TABLE test.users...
> CREATE INDEX "QuotedNameIndex"...
> CREATE INDEX myindex...{code}
> But as described above, tables aren't sorted lexicographically, and a table's
> indexes aren't sorted lexicographically, so output for table test.users can
> come before output for table test.test, and output for index test_val_idx can
> come before output for index test_col_idx. The planned change to the test
> would make it so that the test passes regardless of the order of these like
> objects.
> If lexicographic sorting of objects of like type actually is a requirement
> for DESCRIBE KEYSPACE, then we could fix this by modifying cqlsh
> (duplicative, but simple), or by modifying the Cassandra Python driver's
> cassandra/metadata.py script file (less duplicative but more difficult to
> distribute).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14534) cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
Patrick Bannister created CASSANDRA-14534:
-
Summary: cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is
flaky
Key: CASSANDRA-14534
URL: https://issues.apache.org/jira/browse/CASSANDRA-14534
Project: Cassandra
Issue Type: Test
Components: CQL
Environment: trunk running on Ubuntu 16.04 LTS
Reporter: Patrick Bannister
Fix For: 4.x
*Summary:* test_describe in cqlsh_tests/cqlsh_tests.py::TestCqlsh is flaky. The
test is written to expect the objects of a keyspace to be lexicographically
sorted in DESCRIBE KEYSPACE output. However, this almost never happens, because
the sort order of objects in DESCRIBE KEYSPACE output is arbitrary. I plan to
modify the test to check for expected output without requiring lexicographic
sorting of items of the same type; this work would be rolled up under other
work in CASSANDRA-10190.
This is happening in the Cassandra Python driver, in cassandra.metadata, in the
KeyspaceMetadata and TableMetadata classes. KeyspaceMetadata and TableMetadata
store their child objects in Python dictionaries, and when generating DESCRIBE
output, they visit their child objects in the order returned by the values()
function of each dictionary. The Python dictionary values() function returns
items in an arbitrary order, so they will not necessarily come back sorted
lexicographically as expected by the test.
A simple fix for the test would be to change the way it checks for the expected
output so that the order of objects of the same type is no longer important.
As currently written, the test creates a keyspace like so:
{code:java}
CREATE KEYSPACE test WITH REPLICATION = {'class' : 'SimpleStrategy',
'replication_factor' : 1 };
CREATE TABLE test.users ( userid text PRIMARY KEY, firstname text, lastname
text, age int);
CREATE INDEX myindex ON test.users (age);
CREATE INDEX "QuotedNameIndex" on test.users (firstName);
CREATE TABLE test.test (id int, col int, val text, PRIMARY KEY(id, col));
CREATE INDEX ON test.test (col);
CREATE INDEX ON test.test (val){code}
It expects the output of DESCRIBE KEYSPACE test to appear in the following
order:
{code:java}
CREATE KEYSPACE test...
CREATE TABLE test.test...
CREATE INDEX test_col_idx...
CREATE INDEX test_val_idx...
CREATE TABLE test.users...
CREATE INDEX "QuotedNameIndex"...
CREATE INDEX myindex...{code}
But as described above, tables aren't sorted lexicographically, and a table's
indexes aren't sorted lexicographically, so output for table test.users can
come before output for table test.test, and output for index test_val_idx can
come before output for index test_col_idx. The planned change to the test would
make it so that the test passes regardless of the order of these like objects.
If lexicographic sorting of objects of like type actually is a requirement for
DESCRIBE KEYSPACE, then we could fix this by modifying cqlsh (duplicative, but
simple), or by modifying the Cassandra Python driver's cassandra/metadata.py
script file (less duplicative but more difficult to distribute).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14534) cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518736#comment-16518736
]
Patrick Bannister commented on CASSANDRA-14534:
---
test_describe was developed for CASSANDRA-7814
> cqlsh_tests/cqlsh_tests.py::TestCqlsh::test_describe is flaky
> -
>
> Key: CASSANDRA-14534
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14534
> Project: Cassandra
> Issue Type: Test
> Components: CQL
> Environment: trunk running on Ubuntu 16.04 LTS
>Reporter: Patrick Bannister
>Priority: Minor
> Labels: cqlsh, dtest, flaky-test, test
> Fix For: 4.x
>
>
> *Summary:* test_describe in cqlsh_tests/cqlsh_tests.py::TestCqlsh is flaky.
> The test is written to expect the objects of a keyspace to be
> lexicographically sorted in DESCRIBE KEYSPACE output. However, this almost
> never happens, because the sort order of objects in DESCRIBE KEYSPACE output
> is arbitrary. I plan to modify the test to check for expected output without
> requiring lexicographic sorting of items of the same type; this work would be
> rolled up under other work in CASSANDRA-10190.
> This is happening in the Cassandra Python driver, in cassandra.metadata, in
> the KeyspaceMetadata and TableMetadata classes. KeyspaceMetadata and
> TableMetadata store their child objects in Python dictionaries, and when
> generating DESCRIBE output, they visit their child objects in the order
> returned by the values() function of each dictionary. The Python dictionary
> values() function returns items in an arbitrary order, so they will not
> necessarily come back sorted lexicographically as expected by the test.
> A simple fix for the test would be to change the way it checks for the
> expected output so that the order of objects of the same type is no longer
> important.
> As currently written, the test creates a keyspace like so:
>
> {code:java}
> CREATE KEYSPACE test WITH REPLICATION = {'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE test.users ( userid text PRIMARY KEY, firstname text, lastname
> text, age int);
> CREATE INDEX myindex ON test.users (age);
> CREATE INDEX "QuotedNameIndex" on test.users (firstName);
> CREATE TABLE test.test (id int, col int, val text, PRIMARY KEY(id, col));
> CREATE INDEX ON test.test (col);
> CREATE INDEX ON test.test (val){code}
>
> It expects the output of DESCRIBE KEYSPACE test to appear in the following
> order:
>
> {code:java}
> CREATE KEYSPACE test...
> CREATE TABLE test.test...
> CREATE INDEX test_col_idx...
> CREATE INDEX test_val_idx...
> CREATE TABLE test.users...
> CREATE INDEX "QuotedNameIndex"...
> CREATE INDEX myindex...{code}
> But as described above, tables aren't sorted lexicographically, and a table's
> indexes aren't sorted lexicographically, so output for table test.users can
> come before output for table test.test, and output for index test_val_idx can
> come before output for index test_col_idx. The planned change to the test
> would make it so that the test passes regardless of the order of these like
> objects.
> If lexicographic sorting of objects of like type actually is a requirement
> for DESCRIBE KEYSPACE, then we could fix this by modifying cqlsh
> (duplicative, but simple), or by modifying the Cassandra Python driver's
> cassandra/metadata.py script file (less duplicative but more difficult to
> distribute).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7814) enable describe on indices
[ https://issues.apache.org/jira/browse/CASSANDRA-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517653#comment-16517653 ] Patrick Bannister commented on CASSANDRA-7814: -- Is it a requirement that the output of DESCRIBE should sort things lexicographically? For example, if keyspace test has tables test and users, do we require that the output of DESCRIBE KEYSPACE test should show the test table before the users table? I ask because the dtest for this ticket is very flaky and fails frequently. It's written to expect a specific sort order in the tables and indexes for the output of DESCRIBE KEYSPACE. The root cause is in the cassandra Python driver in cassandra.metadata, because of the implementation of export_as_string() in the KeyspaceMetadata and TableMetadata classes. They visit their child objects in the order returned by the Python dict values() function, which is arbitrary and unsorted. If lexicographic sorting is a requirement, a modification to the Python driver will be needed. If lexicographic sorting is not a requirement, then I could modify the test_describe() dtest to stop caring about the order of objects in the DESCRIBE output. This is coming up in CASSANDRA-10190 (adding Python 3 compatibility to cqlsh). > enable describe on indices > -- > > Key: CASSANDRA-7814 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7814 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: radha >Assignee: Stefania >Priority: Minor > Labels: doc-impacting > Fix For: 2.1.8, 2.2.0 rc2, 3.0 alpha 1 > > > Describe index should be supported, right now, the only way is to export the > schema and find what it really is before updating/dropping the index. > verified in > [cqlsh 3.1.8 | Cassandra 1.2.18.1 | CQL spec 3.0.0 | Thrift protocol 19.36.2] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14489) Test cqlsh authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-14489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister resolved CASSANDRA-14489. --- Resolution: Not A Problem This problem didn't actually exist. > Test cqlsh authentication > - > > Key: CASSANDRA-14489 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14489 > Project: Cassandra > Issue Type: Sub-task >Reporter: Patrick Bannister >Priority: Critical > Labels: cqlsh, security, test > Fix For: 4.x > > > Coverage analysis of the cqlshlib unittests (pylib/cqlshlib/test/test*.py) > and the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no > coverage of authentication related code. > Before we can release a port of cqlsh, we should identify an existing test > for cqlsh authentication, or write a new one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14489) Test cqlsh authentication
[ https://issues.apache.org/jira/browse/CASSANDRA-14489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506718#comment-16506718 ] Patrick Bannister commented on CASSANDRA-14489: --- There are some tests for cqlsh username/password login in the dtests. There are several of them in cqlsh_tests/cqlsh_tests.py::TestCqlLogin. I re-read my coverage report, and in fact, we did observe coverage of connecting with cqlsh using cassandra.auth.PlainTextAuthProvider. Furthermore, the relevant dtests are passing for the pure Python 3 port. We don't have coverage of using the LOGIN command during a connected cqlsh session, but I think it's sufficient that we're already testing the initial login with a password. > Test cqlsh authentication > - > > Key: CASSANDRA-14489 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14489 > Project: Cassandra > Issue Type: Sub-task >Reporter: Patrick Bannister >Priority: Critical > Labels: cqlsh, security, test > Fix For: 4.x > > > Coverage analysis of the cqlshlib unittests (pylib/cqlshlib/test/test*.py) > and the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no > coverage of authentication related code. > Before we can release a port of cqlsh, we should identify an existing test > for cqlsh authentication, or write a new one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14491) Determine how to test cqlsh in a Python 2.7 environment, including dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-14491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505513#comment-16505513 ] Patrick Bannister commented on CASSANDRA-14491: --- It's not critical for the full set of dtests to run under Python 2.7, but we need the cqlsh tests to run if we're going to maintain support for cqlsh to run on Python 2.7. The cqlsh dtests provide a significant portion of the test coverage of cqlsh. I think the dtests should stay on Python 3. The goal is for the cqlsh tests to be runnable on Python 2.7, not to revert. Ideally, I'll make minimal modifications that will be Python 2/3 cross compatible in a single implementation. If the resulting product is good then we'll get to enjoy a more complete test environment; if it's awful then we can stay on Python 3. For what it's worth: I just spent about ninety minutes and changed a few dozen lines of code, and I already have cqlsh_tests/cqlsh_tests.py mostly running under Python 2.7. Hopefully the delta to run on Python 2.7 will be insignificant. > Determine how to test cqlsh in a Python 2.7 environment, including dtests > - > > Key: CASSANDRA-14491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14491 > Project: Cassandra > Issue Type: Sub-task > Environment: > > We need to test with at least two versions of Python: > * Python 2.7 > * Python 3.x (need to determine what versions of Python 3 are available by > default on Ubuntu and RHEL/CentOS) > Additionally, it is recommended to test on at least three platforms: > * Ubuntu or other Debian derivative > * RHEL, CentOS, or other Red Hat derivative > * Windows (unless a consensus has formed around not testing on Windows?) >Reporter: Patrick Bannister >Priority: Major > Labels: cqlsh, test > Fix For: 4.x > > > It appears that a consensus is forming around maintaining Python 2.7 > compatibility for cqlsh. However, the dtests now run in a Python 3 > environment. We need to identify an option for testing infrastructure for > testing cqlsh on Python 2.7, including the dtests. > Based on experience updating the cqlsh dtests, it is strongly recommended to > test in more than one environment - for example, for Linux, we should test on > a Debian derivative as well as a Red Hat derivative. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14491) Determine how to test cqlsh in a Python 2.7 environment, including dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-14491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505374#comment-16505374 ] Patrick Bannister commented on CASSANDRA-14491: --- I'm starting work to try and get the cqlsh_tests dtests working on Python 2.7, so I can run them against the Python 2/3 cqlsh port in a Python 2.7 environment. > Determine how to test cqlsh in a Python 2.7 environment, including dtests > - > > Key: CASSANDRA-14491 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14491 > Project: Cassandra > Issue Type: Sub-task > Environment: > > We need to test with at least two versions of Python: > * Python 2.7 > * Python 3.x (need to determine what versions of Python 3 are available by > default on Ubuntu and RHEL/CentOS) > Additionally, it is recommended to test on at least three platforms: > * Ubuntu or other Debian derivative > * RHEL, CentOS, or other Red Hat derivative > * Windows (unless a consensus has formed around not testing on Windows?) >Reporter: Patrick Bannister >Priority: Major > Labels: cqlsh, test > Fix For: 4.x > > > It appears that a consensus is forming around maintaining Python 2.7 > compatibility for cqlsh. However, the dtests now run in a Python 3 > environment. We need to identify an option for testing infrastructure for > testing cqlsh on Python 2.7, including the dtests. > Based on experience updating the cqlsh dtests, it is strongly recommended to > test in more than one environment - for example, for Linux, we should test on > a Debian derivative as well as a Red Hat derivative. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504070#comment-16504070 ] Patrick Bannister commented on CASSANDRA-10190: --- In discussion on the cassandra-dev list, a consensus formed around maintaining support for Python 2. I'm working on making the cqlsh port to Python 3 cross-compatible with Python 2.7. The goal is a single cross-compatible implementation. I'm making progress and I suspect the port will be the easy part. Getting testing infrax right to support both versions will probably be more complex. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14494) Investigate possibility of a cqlsh terminfo
Patrick Bannister created CASSANDRA-14494:
-
Summary: Investigate possibility of a cqlsh terminfo
Key: CASSANDRA-14494
URL: https://issues.apache.org/jira/browse/CASSANDRA-14494
Project: Cassandra
Issue Type: Sub-task
Environment: This behavior has been observed in xterm on CentOS 7.5
platforms. The test_cqlsh_output.py unit tests
(pylib/cqlshlib/test/test_cqlsh_output.py) are a good place to see it in action.
Reporter: Patrick Bannister
Fix For: 4.x
Summary: investigate whether we could use a cqlsh-specific terminfo file to
prevent use of the set-meta-mode escape sequence in xterm without breaking
colors. If it works, see if we can install it in an appropriate place using
Python distutils. If yes to both, generate a cqlsh terminfo file and work it
into the install process.
Long detailed explanation:
In some more recent environments, in Python REPL applications that use the
readline module, the set meta mode escape sequence is output before each
prompt. This escape sequence has caused problems for some applications, and in
our case, some of our cqlsh unit tests
(pylib/cqlshlib/test/test_cqlsh_output.py) choke on this output because of the
way our tests are designed to detect the cqlsh prompt. This behavior was
observed on a CentOS 7.5 platform.
The set-meta-mode escape sequence normally appears as "[?1034h" in output; it's
normally defined as the bytes 1b 5b 3f 31 30 33 34 68. The exact value of the
escape sequence is configurable and may be found on a GNU/Linux platform by
running the command:
{code:java}
tput smm | hexdump{code}
If this command gives no output, then the set meta mode sequence is not defined
on this platform for the terminal in use. Refer to the xterm and terminfo man
pages for more information on this sequence.
There are easier ways to solve this problem for the sake of the unit test, but
if time allows, I'd like to look into this to achieve a more consistent output
behavior for cqlsh on GNU/Linux platforms.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499263#comment-16499263 ] Patrick Bannister commented on CASSANDRA-10190: --- I added several subtasks to this ticket for testing of the areas that were not covered according to my coverage report. (Refuting the coverage report by identifying an existing test for the supposedly uncovered features would be superior to writing a new test.) > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14493) Test describe statements for aggregates, functions, indexes, schemas, types, and user types
Patrick Bannister created CASSANDRA-14493: - Summary: Test describe statements for aggregates, functions, indexes, schemas, types, and user types Key: CASSANDRA-14493 URL: https://issues.apache.org/jira/browse/CASSANDRA-14493 Project: Cassandra Issue Type: Sub-task Reporter: Patrick Bannister Fix For: 4.x Coverage analysis of the cqlsh unittests (pylib/cqlshlib/test/test*.py) and the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no coverage of functions for describing aggregates, functions, indexes, schemas, types, or usertypes. Before we can release a ported cqlsh, we should either create a new test that exercises these kinds of describe statements, or refute the coverage report by identifying an existing test for these features. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14492) Test use of thousands separators and comma decimal separators
Patrick Bannister created CASSANDRA-14492:
-
Summary: Test use of thousands separators and comma decimal
separators
Key: CASSANDRA-14492
URL: https://issues.apache.org/jira/browse/CASSANDRA-14492
Project: Cassandra
Issue Type: Sub-task
Reporter: Patrick Bannister
Fix For: 4.x
Coverage analysis showed no coverage for functions related to displaying
numbers with thousands separators ("$100,000,000,000" instead of
"$1000") and displaying numbers with custom decimal separators
("3,1415927" instead of "3.1415927").
We should add a test that displays numbers like this, or identify an existing
test that does it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14491) Determine how to test cqlsh in a Python 2.7 environment, including dtests
Patrick Bannister created CASSANDRA-14491: - Summary: Determine how to test cqlsh in a Python 2.7 environment, including dtests Key: CASSANDRA-14491 URL: https://issues.apache.org/jira/browse/CASSANDRA-14491 Project: Cassandra Issue Type: Sub-task Environment: We need to test with at least two versions of Python: * Python 2.7 * Python 3.x (need to determine what versions of Python 3 are available by default on Ubuntu and RHEL/CentOS) Additionally, it is recommended to test on at least three platforms: * Ubuntu or other Debian derivative * RHEL, CentOS, or other Red Hat derivative * Windows (unless a consensus has formed around not testing on Windows?) Reporter: Patrick Bannister Fix For: 4.x It appears that a consensus is forming around maintaining Python 2.7 compatibility for cqlsh. However, the dtests now run in a Python 3 environment. We need to identify an option for testing infrastructure for testing cqlsh on Python 2.7, including the dtests. Based on experience updating the cqlsh dtests, it is strongly recommended to test in more than one environment - for example, for Linux, we should test on a Debian derivative as well as a Red Hat derivative. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14490) Test displaying CJK languages
Patrick Bannister created CASSANDRA-14490: - Summary: Test displaying CJK languages Key: CASSANDRA-14490 URL: https://issues.apache.org/jira/browse/CASSANDRA-14490 Project: Cassandra Issue Type: Sub-task Reporter: Patrick Bannister Fix For: 4.0.x Coverage analysis of cqlsh tests showed no coverage of wcwidth functions related to displaying CJK languages. Before releasing a port, we should identify or create a test that exercises code paths for displaying CJK language data in cqlsh. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14489) Test cqlsh authentication
Patrick Bannister created CASSANDRA-14489: - Summary: Test cqlsh authentication Key: CASSANDRA-14489 URL: https://issues.apache.org/jira/browse/CASSANDRA-14489 Project: Cassandra Issue Type: Sub-task Reporter: Patrick Bannister Fix For: 4.x Coverage analysis of the cqlshlib unittests (pylib/cqlshlib/test/test*.py) and the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no coverage of authentication related code. Before we can release a port of cqlsh, we should identify an existing test for cqlsh authentication, or write a new one. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498851#comment-16498851 ] Patrick Bannister commented on CASSANDRA-10190: --- [~jolynch], thanks! Help figuring out the testing infrastructure would be much appreciated, I don't have any experience with tox yet. Right now I'm testing on AWS EC2 instances, I haven't made the jump to CI systems yet. I'll add some subtasks to this ticket to address our testing gaps - authentication, Windows, displaying CJK languages, describe statements, and use of commas for thousands separators and decimal separators are the concrete items I think are urgent. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497274#comment-16497274 ] Patrick Bannister commented on CASSANDRA-10190: --- I ran the cqlshlib unittests (cassandra/pylib/cqlshlib/test/test_*.py) and the dtest cqlsh_tests under coverage.py. There are a few blind spots in the tests. Notes attached in coverage_notes.txt. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-10190: -- Attachment: coverage_notes.txt > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494568#comment-16494568 ] Patrick Bannister commented on CASSANDRA-14298: --- [~spo...@gmail.com] - I attached a new patch (CASSANDRA-14298.txt) with the files cqlsh_tests.py and cqlsh_copy_tests.py renamed to test_cqlsh.py and test_cqlsh_copy.py, respectively. The patch still has a check in the setUp fixture that adds LC_CTYPE=en_US.utf8 to the environment if locale.getpreferredencoding() is not UTF-8. If you feel strongly that we should not do this, I'd be willing to remove it, but I recommend we keep it. For people who run outside of the cassandra-builds dtest wrapper environment, this may prevent some configuration headaches during testing. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: CASSANDRA-14298.txt > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: (was: CASSANDRA-14298.txt) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492955#comment-16492955 ] Patrick Bannister commented on CASSANDRA-14298: --- [~spo...@gmail.com], no worries about having to multitask, I appreciate the significant time you've put into working with me on this ticket. I'll update the patch to rename the files. I'll email the dev list about porting as soon as I finish coverage analysis (working actively on that today). > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491877#comment-16491877 ] Patrick Bannister commented on CASSANDRA-14298: --- I just noticed [this discussion of this ticket|https://wilderness.apache.org/channels/?f=cassandra-dev/2018-05-17] on the #cassandra-dev IRC channel. Would you like me to reissue this patch with the files renamed to test_cqlsh.py and test_cqlsh_copy.py? > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16491212#comment-16491212 ] Patrick Bannister commented on CASSANDRA-14298: --- OK - I left up the "old" patch that didn't change the environment variable, if you prefer that approach. I'm going to move any further comments of porting cqlshlib to CASSANDRA-10190. I also plan to email the dev list about it after I put together some kind of code coverage analysis. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490904#comment-16490904 ] Patrick Bannister commented on CASSANDRA-10190: --- Discussion of porting, testing, and fixing cqlsh_tests, including tests that depend on cqlshlib. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16490899#comment-16490899 ] Patrick Bannister commented on CASSANDRA-10190: --- Python 2.7 end of life, including security updates, is planned for 1 January 2020. We should port cqlshlib to Python 3, or make it Python 2.7/3.x cross compatible. I'm close to finishing a port to Python 3 that passes almost all of the cqlshlib unittests and the dtest cqlsh_tests on Ubuntu 16.04 LTS and CentOS 7.5 - I'm just working out some environmental issues that manifest on CentOS. Regardless of whether we go to straight Python 3 or a 2/3 cross compatible implementation, we have to get things working in Python 3. ([http://python3porting.com/strategies.html] has a good discussion on this point.) If we go with a cross compatible implementation, we would introduce complexity and carry a long term technical debt. For that reason, I personally prefer a straight Python 3 implementation. However, it may be easier for many users to transition to a cross compatible implementation, so we should at least consider it. Thorough testing would be important. After I get all the tests running, I'm planning to use [coverage.py|https://coverage.readthedocs.io/en/coverage-4.5.1] to identify areas of cqlshlib that aren't well tested by our current tests, so we'll know what features need more scrutiny. We will probably need users to help with testing if we hope to catch all the bugs. > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Status: Patch Available (was: Open) Please see attachment CASSSANDRA-14298.txt for a new patch to cassandra-dtest that passes on trunk, cassandra-3.11, and cassandra-3.0 on CentOS 7.5 and Ubuntu 16.04 LTS on AWS t2.large instances. In this patch, the setUpClass() function for cqlsh_tests.py::TestCqlsh and cqlsh_copy_tests.py::TestCqlshCopy checks the system preferred encoding with locale.getpreferredencoding(), and if the result isn't UTF-8, it sets LC_CTYPE=en_US.utf8. This locale is more widely available. On systems where en_US.utf8 isn't available, the tests will fail unless some other UTF-8 locale is set. I've noticed that the bulk round trip tests in cqlsh_tests/cqlsh_copy_tests::TestCqlshCopy are flaky. When they've failed, they've consistently passed when rerun. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: CASSANDRA-14298.txt > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Status: Open (was: Patch Available) Testing modifications that should work on Red Hat variants in addition to Ubuntu. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Bannister updated CASSANDRA-14298: -- Attachment: (was: CASSANDRA-14298.txt) > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489680#comment-16489680 ] Patrick Bannister commented on CASSANDRA-14298: --- [~spo...@gmail.com], I've been cluttering up this ticket with lots of discussion of testing the cqlshlib port to Python 3, but I think I'd like to move that to a new ticket and try to close up this one according to our original plan: deselect tests that depend on cqlshlib and fix everything else. I'm testing a new CASSANDRA-14298 patch that will try to use LC_CTYPE=en_US.UTF-8. If it works on Ubuntu 16.04 LTS and CentOS, I'll submit it. Does all that sound good to you? > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16488331#comment-16488331 ] Patrick Bannister commented on CASSANDRA-14298: --- I switched to CentOS instead of RHEL, since RHEL requires a license to get access to the packages for many of the C* dependencies. Things look okay for the dtests on CentOS for these modifications using LC_CTYPE=en_US.utf8. That includes the cqlshlib port to Pyfhon 3 too. There are some extensive failures for the cqlshlib unittests in CentOS. cqlshlib/test/run_cqlsh.py::ProcRunner::read_until() can't handle ANSI control characters for colors in the prompt. I was able to modify the regular expression to handle the escape sequences, and with that change, the tests pass. But I won't be happy with that solution until I figure out why these escape characters are showing up in CentOS but not in my usual Ubuntu environment. The inputrc and bashrc files are a bit different, but I haven't figured out yet which difference, if any, is making the CentOS cqlsh prompt include colors. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483150#comment-16483150 ] Patrick Bannister commented on CASSANDRA-14298: --- I think I need to retract my recommendation to use LC_CTYPE=C.UTF-8. I learned this weekend that the C.UTF-8 locale is somewhat specific to Debian. (It's also available on more recent versions of Fedora, as an optional add-on.) I recommended it initially because it's more internationalization friendly than picking a single language such as en_US.UTF-8. Unfortunately, since it's specific to the Debian family, I think that makes it a poor choice for testing. For the lack of a better solution, I recommend we use LC_CTYPE=en_US.UTF-8. Also - I'm working on standing up a RHEL 7.5 instance on AWS to test my work on a different environment, to make sure there aren't more hidden environmental dependencies like this. Separately, as an update on the cqlshlib porting work: my forks of cassandra and cassandra-dtest have cqlshlib3 branches with cqlshlib ported to straight Python 3, with all cqlshlib unittests and all dtest cqlsh_tests passing, except for test_describe (in test_cqlsh_output.py in the cqlshlib unit tests) and test_unusual_dates (in cqlsh_tests.py in the dtests). I still want to try to measure coverage (not sure how that's going to work with the dtests but it should be doable with the unittests), and I definitely want to test these on RHEL or some other non-Debian environment; I'll continue with that work this week. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16481393#comment-16481393 ] Patrick Bannister commented on CASSANDRA-14298: --- Regarding my concerns about code coverage - once I get the cqlshlib unit tests and dtests working, I'll experiment with [coverage.py|https://coverage.readthedocs.io/en/coverage-4.5.1/] and see if I can get a useful analysis of our code coverage. This would help us plan where to spend effort doing extra testing. > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14298) cqlshlib tests broken on b.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-14298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479921#comment-16479921 ] Patrick Bannister commented on CASSANDRA-14298: --- Too bad the programmatic environment setting didn't work! It must be environmental - I'll have to start testing my patches on multiple flavors of Linux to help catch these kind of issues. As for taking the cqlshlib porting question to the dev list, I agree that now is a good time. Did you plan for you or Marcus to write the email, or would you like me to write it? > cqlshlib tests broken on b.a.o > -- > > Key: CASSANDRA-14298 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14298 > Project: Cassandra > Issue Type: Bug > Components: Build, Testing >Reporter: Stefan Podkowinski >Assignee: Patrick Bannister >Priority: Major > Labels: cqlsh, dtest > Attachments: CASSANDRA-14298-old.txt, CASSANDRA-14298.txt, > cqlsh_tests_notes.md > > > It appears that cqlsh-tests on builds.apache.org on all branches stopped > working since we removed nosetests from the system environment. See e.g. > [here|https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-cqlsh-tests/458/cython=no,jdk=JDK%201.8%20(latest),label=cassandra/console]. > Looks like we either have to make nosetests available again or migrate to > pytest as we did with dtests. Giving pytest a quick try resulted in many > errors locally, but I haven't inspected them in detail yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
