[jira] [Updated] (CASSANDRA-17235) Add diagnostic events for unavailable errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-17235: --- Test and Documentation Plan: (was: PR: https://github.com/apache/cassandra/pull/1375 CI: https://app.circleci.com/pipelines/github/spodkowinski/cassandra?branch=unavail_events=all) PR: https://github.com/apache/cassandra/pull/1375 CI: https://app.circleci.com/pipelines/github/spodkowinski/cassandra?branch=unavail_events=all > Add diagnostic events for unavailable errors > > > Key: CASSANDRA-17235 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17235 > Project: Cassandra > Issue Type: New Feature > Components: Observability/JMX >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Errors from unavailables during query execution lack important details on the > context why the error occurred. Emitting diagnostic events on unavailables > will allow you to attach to the instance during troubleshooting and observe > the type of operation (what kind of reads/writes), keyspace replication > settings and down nodes as seen by the instance throwing the error. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17235) Add diagnostic events for unavailable errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-17235: --- Test and Documentation Plan: PR: https://github.com/apache/cassandra/pull/1375 CI: https://app.circleci.com/pipelines/github/spodkowinski/cassandra?branch=unavail_events=all Status: Patch Available (was: Open) > Add diagnostic events for unavailable errors > > > Key: CASSANDRA-17235 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17235 > Project: Cassandra > Issue Type: New Feature > Components: Observability/JMX >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Errors from unavailables during query execution lack important details on the > context why the error occurred. Emitting diagnostic events on unavailables > will allow you to attach to the instance during troubleshooting and observe > the type of operation (what kind of reads/writes), keyspace replication > settings and down nodes as seen by the instance throwing the error. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17235) Add diagnostic events for unavailable errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-17235: --- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Add diagnostic events for unavailable errors > > > Key: CASSANDRA-17235 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17235 > Project: Cassandra > Issue Type: New Feature > Components: Observability/JMX >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Errors from unavailables during query execution lack important details on the > context why the error occurred. Emitting diagnostic events on unavailables > will allow you to attach to the instance during troubleshooting and observe > the type of operation (what kind of reads/writes), keyspace replication > settings and down nodes as seen by the instance throwing the error. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17235) Add diagnostic events for unavailable errors
Stefan Podkowinski created CASSANDRA-17235: -- Summary: Add diagnostic events for unavailable errors Key: CASSANDRA-17235 URL: https://issues.apache.org/jira/browse/CASSANDRA-17235 Project: Cassandra Issue Type: New Feature Components: Observability/JMX Reporter: Stefan Podkowinski Assignee: Stefan Podkowinski Errors from unavailables during query execution lack important details on the context why the error occurred. Emitting diagnostic events on unavailables will allow you to attach to the instance during troubleshooting and observe the type of operation (what kind of reads/writes), keyspace replication settings and down nodes as seen by the instance throwing the error. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17130) Log missing peers in StartupClusterConnectivityChecker
[ https://issues.apache.org/jira/browse/CASSANDRA-17130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17441901#comment-17441901 ] Stefan Podkowinski commented on CASSANDRA-17130: +1 > Log missing peers in StartupClusterConnectivityChecker > -- > > Key: CASSANDRA-17130 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17130 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > It would be helpful to get actual peers logged that we haven't been able to > ping. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17130) Log missing peers in StartupClusterConnectivityChecker
[ https://issues.apache.org/jira/browse/CASSANDRA-17130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-17130: --- Reviewers: Berenguer Blasi, Stefan Podkowinski (was: Berenguer Blasi) > Log missing peers in StartupClusterConnectivityChecker > -- > > Key: CASSANDRA-17130 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17130 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > It would be helpful to get actual peers logged that we haven't been able to > ping. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15823) Support for networking via identity instead of IP
[ https://issues.apache.org/jira/browse/CASSANDRA-15823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200662#comment-17200662 ] Stefan Podkowinski commented on CASSANDRA-15823: DNS is not strongly consistent and hard to reason about when making DNS a part of your system. We should not rely on address translation when thinking about consistency invariants. The title of the issue says "Support for networking via identity instead of IP". We should already be able to add some support for identities without using hostnames, in case we enable internode encryption. X509 certificates are issued with a unique identity. If you create an outgoing connection to a host, you should be able to compare the hostname of the peers certificate you're connecting to, with the hostname you've seen before for that IP and fail in case they wouldn't match. But this is really just useful for failing hard on IP swapping situations and not a basis for enabling a more advanced service mesh integration you've been mentioning. > Support for networking via identity instead of IP > - > > Key: CASSANDRA-15823 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15823 > Project: Cassandra > Issue Type: Improvement >Reporter: Christopher Bradford >Priority: Normal > Labels: kubernetes > Attachments: consul-mesh-gateways.png, > istio-multicluster-with-gateways.svg, linkerd-service-mirroring.svg > > > TL;DR: Instead of mapping host ids to IPs, use hostnames. This allows > resolution to different IP addresses per DC that may then be forwarded to > nodes on remote networks without requiring node to node IP connectivity for > cross-dc links. > > This approach should not affect existing deployments as those could continue > to use IPs as the hostname and skip resolution. > > With orchestration platforms like Kubernetes and the usage of ephemeral > containers in environments today we should consider some changes to how we > handle the tracking of nodes and their network location. Currently we > maintain a mapping between host ids and IP addresses. > > With traditional infrastructure, if a node goes down it, usually, comes back > up with the same IP. In some environments this contract may be explicit with > virtual IPs that may move between hosts. In newer deployments, like on > Kubernetes, this contract is not possible. Pods (analogous to nodes) are > assigned an IP address at start time. Should the pod be restarted or > scheduled on a different host there is no guarantee we would have the same > IP. Cassandra is protected here as we already have logic in place to update > peers when we come up with the same host id, but a different IP address. > > There are ways to get Kubernetes to assign a specific IP per Pod. Most > recommendations involve the use of a service per pod. Communication with the > fixed service IP would automatically forward to the associated pod, > regardless of address. We _could_ use this approach, but it seems like this > would needlessly create a number of extra resources in our k8s cluster to get > around the problem. Which, to be fair, doesn't seem like much of a problem > with the aforementioned mitigations built into C*. > > So what is the _actual_ problem? *Cross-region, cross-cloud, > hybrid-deployment connectivity between pods is a pain.* This can be solved > with significant investment by those who want to deploy these types of > topologies. You can definitely configure connectivity between clouds over > dedicated connections, or VPN tunnels. With a big chunk of time insuring that > pod to pod connectivity just works even if those pods are managed by separate > control planes, but that again requires time and talent. There are a number > of edge cases to support between the ever so slight, but very important, > differences in cloud vendor networks. > > Recently there have been a number of innovations that aid in the deployment > and operation of these types of applications on Kubernetes. Service meshes > support distributed microservices running across multiple k8s cluster control > planes in disparate networks. Instead of directly connecting to IP addresses > of remote services instead they use a hostname. With this approach, hostname > traffic may then be routed to a proxy that sends traffic over the WAN > (sometimes with mTLS) to another proxy pod in the remote cluster which then > forwards the data along to the correct pod in that network. (See attached > diagrams) > > Which brings us to the point of this ticket. Instead of mapping host ids to > IPs, use hostnames (and update the underlying address periodically instead of > caching indefinitely). This allows resolution to different IP addresses per > DC (k8s cluster)
[jira] [Commented] (CASSANDRA-14712) Add fqltool and auditlogviewer to rpm and deb packages
[ https://issues.apache.org/jira/browse/CASSANDRA-14712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17123853#comment-17123853 ] Stefan Podkowinski commented on CASSANDRA-14712: The ticket was created quite a while ago, thanks for confirming that most of the described issues have been solved by now! > Add fqltool and auditlogviewer to rpm and deb packages > -- > > Key: CASSANDRA-14712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14712 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Stefan Podkowinski >Assignee: Stefan Miklosovic >Priority: Normal > Labels: Java11, pull-request-available > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently it's not possible to build any native packages (.deb/.rpm) for > trunk. > cassandra-builds - docker/*-image.docker > * Add Java11 to debian+centos build image > * (packaged ant scripts won't work with Java 11 on centos, so we may have to > install ant from tarballs) > cassandra-builds - docker/build-*.sh > * set JAVA8_HOME to Java8 > * set JAVA_HOME to Java11 (4.0) or Java8 (<4.0) > cassandra - redhat/cassandra.spec > * Check if patches still apply after CASSANDRA-14707 > * Add fqltool as %files > We may also have to change the version handling in build.xml or build-*.sh, > depending how we plan to release packages during beta, or if we plan to do so > at all before GA. -- 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] [Updated] (CASSANDRA-14712) Add fqltool and auditlogviewer to rpm and deb packages
[ https://issues.apache.org/jira/browse/CASSANDRA-14712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14712: --- Summary: Add fqltool and auditlogviewer to rpm and deb packages (was: Cassandra 4.0 packaging support) > Add fqltool and auditlogviewer to rpm and deb packages > -- > > Key: CASSANDRA-14712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14712 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Stefan Podkowinski >Assignee: Stefan Miklosovic >Priority: Normal > Labels: Java11, pull-request-available > Fix For: 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently it's not possible to build any native packages (.deb/.rpm) for > trunk. > cassandra-builds - docker/*-image.docker > * Add Java11 to debian+centos build image > * (packaged ant scripts won't work with Java 11 on centos, so we may have to > install ant from tarballs) > cassandra-builds - docker/build-*.sh > * set JAVA8_HOME to Java8 > * set JAVA_HOME to Java11 (4.0) or Java8 (<4.0) > cassandra - redhat/cassandra.spec > * Check if patches still apply after CASSANDRA-14707 > * Add fqltool as %files > We may also have to change the version handling in build.xml or build-*.sh, > depending how we plan to release packages during beta, or if we plan to do so > at all before GA. -- 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-15686) Improvements in circle CI default config
[
https://issues.apache.org/jira/browse/CASSANDRA-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17078419#comment-17078419
]
Stefan Podkowinski commented on CASSANDRA-15686:
"there is no guidance or document saying they are not reliable on low config"
Can we update the README mentioned above on that?
> Improvements in circle CI default config
>
>
> Key: CASSANDRA-15686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15686
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Kevin Gallardo
>Priority: Normal
>
> I have been looking at and played around with the [default CircleCI
> config|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml],
> a few comments/questions regarding the following topics:
> * Python dtests do not run successfully (200-300 failures) on {{medium}}
> instances, they seem to only run with small flaky failures on {{large}}
> instances or higher
> * Python Upgrade tests:
> ** Do not seem to run without many failures on any instance types / any
> parallelism setting
> ** Do not seem to parallelize well, it seems each container is going to
> download multiple C* versions
> ** Additionally it seems the configuration is not up to date, as currently
> we get errors because {{JAVA8_HOME}} is not set
> * Unit tests do not seem to parallelize optimally, number of test runners do
> not reflect the available CPUs on the container. Ideally if # of runners == #
> of CPUs, build time is improved, on any type of instances.
> ** For instance when using the current configuration, running on medium
> instances, build will use 1 junit test runner, but 2 CPUs are available. If
> using 2 runners, the build time is reduced from 19min (at the current main
> config of parallelism=4) to 12min.
> * There are some typos in the file, some dtests say "Run Unit Tests" but
> they are JVM dtests (see
> [here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L1077],
>
> [here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L1386])
> So some ways to process these would be:
> * Do the Python dtests run successfully for anyone on {{medium}} instances?
> If not, would it make sense to bump them to {{large}} so that they can be run
> successfully?
> * Does anybody ever run the python upgrade tests on CircleCI and what is the
> configuration that makes it work?
> * Would it make sense to either hardcode the number of test runners in the
> unit tests with `-Dtest.runners` in the config file to reflect the number of
> CPUs on the instances, or change the build so that it is able to detect the
> appropriate number of core available automatically?
> Additionally, it seems this default config file (config.yml) is not as well
> maintained as the
> [{{config-2_1.yml}}|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml]
> (+its lowres/highres) version in the same folder (from CASSANDRA-14806).
> What is the reasoning for maintaining these 2 versions of the build? Could
> the better maintained version be used as the default? We could generate a
> lowres version of the new config-2_1.yml, and rename it {{config.yml}} so
> that it gets picked up by CircleCI automatically instead of the current
> default.
--
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-15686) Improvements in circle CI default config
[
https://issues.apache.org/jira/browse/CASSANDRA-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17078414#comment-17078414
]
Stefan Podkowinski commented on CASSANDRA-15686:
I understand that it can be confusing to have tests available to run that have
literally no chance to complete successfully using the low-res settings. But if
you look at the
[README|https://github.com/apache/cassandra/tree/trunk/.circleci] you'll see
that we use the same file `config-2_1.yml` and just patch it for high-res
settings. The idea was not having to maintain two versions of circle config
files.
> Improvements in circle CI default config
>
>
> Key: CASSANDRA-15686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15686
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Kevin Gallardo
>Priority: Normal
>
> I have been looking at and played around with the [default CircleCI
> config|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml],
> a few comments/questions regarding the following topics:
> * Python dtests do not run successfully (200-300 failures) on {{medium}}
> instances, they seem to only run with small flaky failures on {{large}}
> instances or higher
> * Python Upgrade tests:
> ** Do not seem to run without many failures on any instance types / any
> parallelism setting
> ** Do not seem to parallelize well, it seems each container is going to
> download multiple C* versions
> ** Additionally it seems the configuration is not up to date, as currently
> we get errors because {{JAVA8_HOME}} is not set
> * Unit tests do not seem to parallelize optimally, number of test runners do
> not reflect the available CPUs on the container. Ideally if # of runners == #
> of CPUs, build time is improved, on any type of instances.
> ** For instance when using the current configuration, running on medium
> instances, build will use 1 junit test runner, but 2 CPUs are available. If
> using 2 runners, the build time is reduced from 19min (at the current main
> config of parallelism=4) to 12min.
> * There are some typos in the file, some dtests say "Run Unit Tests" but
> they are JVM dtests (see
> [here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L1077],
>
> [here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L1386])
> So some ways to process these would be:
> * Do the Python dtests run successfully for anyone on {{medium}} instances?
> If not, would it make sense to bump them to {{large}} so that they can be run
> successfully?
> * Does anybody ever run the python upgrade tests on CircleCI and what is the
> configuration that makes it work?
> * Would it make sense to either hardcode the number of test runners in the
> unit tests with `-Dtest.runners` in the config file to reflect the number of
> CPUs on the instances, or change the build so that it is able to detect the
> appropriate number of core available automatically?
> Additionally, it seems this default config file (config.yml) is not as well
> maintained as the
> [{{config-2_1.yml}}|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml]
> (+its lowres/highres) version in the same folder (from CASSANDRA-14806).
> What is the reasoning for maintaining these 2 versions of the build? Could
> the better maintained version be used as the default? We could generate a
> lowres version of the new config-2_1.yml, and rename it {{config.yml}} so
> that it gets picked up by CircleCI automatically instead of the current
> default.
--
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-15686) Improvements in circle CI default config
[
https://issues.apache.org/jira/browse/CASSANDRA-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17078223#comment-17078223
]
Stefan Podkowinski edited comment on CASSANDRA-15686 at 4/8/20, 12:14 PM:
--
Unit tests should be able to complete on Circle CI with medium instances. The
unit tests are run automatically, so that's the default. Pretty much all others
won't due to limited resources. You shouldn't try running them, but if you do,
then we can't guarantee they may complete unless high resource settings are
used.
was (Author: spo...@gmail.com):
Unit tests should be able to complete on Circle CI with medium instances. The
unit tests are run automatically, so that's the default. Pretty much all others
won't due to limited resources. You shouldn't try running them, but if you do,
then we can guarantee they may complete unless high resource settings are used.
> Improvements in circle CI default config
>
>
> Key: CASSANDRA-15686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15686
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Kevin Gallardo
>Priority: Normal
>
> I have been looking at and played around with the [default CircleCI
> config|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml],
> a few comments/questions regarding the following topics:
> * Python dtests do not run successfully (200-300 failures) on {{medium}}
> instances, they seem to only run with small flaky failures on {{large}}
> instances or higher
> * Python Upgrade tests:
> ** Do not seem to run without many failures on any instance types / any
> parallelism setting
> ** Do not seem to parallelize well, it seems each container is going to
> download multiple C* versions
> ** Additionally it seems the configuration is not up to date, as currently
> we get errors because {{JAVA8_HOME}} is not set
> * Unit tests do not seem to parallelize optimally, number of test runners do
> not reflect the available CPUs on the container. Ideally if # of runners == #
> of CPUs, build time is improved, on any type of instances.
> ** For instance when using the current configuration, running on medium
> instances, build will use 1 junit test runner, but 2 CPUs are available. If
> using 2 runners, the build time is reduced from 19min (at the current main
> config of parallelism=4) to 12min.
> * There are some typos in the file, some dtests say "Run Unit Tests" but
> they are JVM dtests (see
> [here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L1077],
>
> [here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L1386])
> So some ways to process these would be:
> * Do the Python dtests run successfully for anyone on {{medium}} instances?
> If not, would it make sense to bump them to {{large}} so that they can be run
> successfully?
> * Does anybody ever run the python upgrade tests on CircleCI and what is the
> configuration that makes it work?
> * Would it make sense to either hardcode the number of test runners in the
> unit tests with `-Dtest.runners` in the config file to reflect the number of
> CPUs on the instances, or change the build so that it is able to detect the
> appropriate number of core available automatically?
> Additionally, it seems this default config file (config.yml) is not as well
> maintained as the
> [{{config-2_1.yml}}|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml]
> (+its lowres/highres) version in the same folder (from CASSANDRA-14806).
> What is the reasoning for maintaining these 2 versions of the build? Could
> the better maintained version be used as the default? We could generate a
> lowres version of the new config-2_1.yml, and rename it {{config.yml}} so
> that it gets picked up by CircleCI automatically instead of the current
> default.
--
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-15686) Improvements in circle CI default config
[
https://issues.apache.org/jira/browse/CASSANDRA-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17078223#comment-17078223
]
Stefan Podkowinski commented on CASSANDRA-15686:
Unit tests should be able to complete on Circle CI with medium instances. The
unit tests are run automatically, so that's the default. Pretty much all others
won't due to limited resources. You shouldn't try running them, but if you do,
then we can guarantee they may complete unless high resource settings are used.
> Improvements in circle CI default config
>
>
> Key: CASSANDRA-15686
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15686
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Kevin Gallardo
>Priority: Normal
>
> I have been looking at and played around with the [default CircleCI
> config|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml],
> a few comments/questions regarding the following topics:
> * Python dtests do not run successfully (200-300 failures) on {{medium}}
> instances, they seem to only run with small flaky failures on {{large}}
> instances or higher
> * Python Upgrade tests:
> ** Do not seem to run without many failures on any instance types / any
> parallelism setting
> ** Do not seem to parallelize well, it seems each container is going to
> download multiple C* versions
> ** Additionally it seems the configuration is not up to date, as currently
> we get errors because {{JAVA8_HOME}} is not set
> * Unit tests do not seem to parallelize optimally, number of test runners do
> not reflect the available CPUs on the container. Ideally if # of runners == #
> of CPUs, build time is improved, on any type of instances.
> ** For instance when using the current configuration, running on medium
> instances, build will use 1 junit test runner, but 2 CPUs are available. If
> using 2 runners, the build time is reduced from 19min (at the current main
> config of parallelism=4) to 12min.
> * There are some typos in the file, some dtests say "Run Unit Tests" but
> they are JVM dtests (see
> [here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L1077],
>
> [here|https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L1386])
> So some ways to process these would be:
> * Do the Python dtests run successfully for anyone on {{medium}} instances?
> If not, would it make sense to bump them to {{large}} so that they can be run
> successfully?
> * Does anybody ever run the python upgrade tests on CircleCI and what is the
> configuration that makes it work?
> * Would it make sense to either hardcode the number of test runners in the
> unit tests with `-Dtest.runners` in the config file to reflect the number of
> CPUs on the instances, or change the build so that it is able to detect the
> appropriate number of core available automatically?
> Additionally, it seems this default config file (config.yml) is not as well
> maintained as the
> [{{config-2_1.yml}}|https://github.com/apache/cassandra/blob/trunk/.circleci/config-2_1.yml]
> (+its lowres/highres) version in the same folder (from CASSANDRA-14806).
> What is the reasoning for maintaining these 2 versions of the build? Could
> the better maintained version be used as the default? We could generate a
> lowres version of the new config-2_1.yml, and rename it {{config.yml}} so
> that it gets picked up by CircleCI automatically instead of the current
> default.
--
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=17073621#comment-17073621 ] Stefan Podkowinski commented on CASSANDRA-15659: Instruction on circle CI docker images can be found here: https://github.com/apache/cassandra-builds/tree/master/docker/testing > 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 >Assignee: Eduard Tudenhoefner >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Time Spent: 40m > Remaining Estimate: 0h > > 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] [Updated] (CASSANDRA-15620) Add "unleveled sstables" table metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15620: --- Fix Version/s: 4.0-alpha Source Control Link: https://github.com/apache/cassandra/commit/1916e5d1ca6ed526a65c4fef7ff933de70006496 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as 1916e5d1ca6ed526a65c4fef7ff933de70006496 > Add "unleveled sstables" table metric > - > > Key: CASSANDRA-15620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15620 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > Fix For: 4.0-alpha > > > The number of unleveled sstables is an important indicator that deserves to > be a dedicated table metric on its own. This will also add a global gauge > that is convenient to query. -- 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-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055118#comment-17055118
]
Stefan Podkowinski commented on CASSANDRA-15313:
Reverting CASSANDRA-1 fixes corruptionCausesFailure with seed
71671740653044L for me. But semantics for generators change with that as well,
so I'm not 100% sure its the actual cause.
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: CASSANDRA-15313-hack.patch
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
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-15620) Add "unleveled sstables" table metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051057#comment-17051057 ] Stefan Podkowinski commented on CASSANDRA-15620: * [CASSANDRA-15620|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-15620] * [!https://circleci.com/gh/spodkowinski/cassandra/tree/CASSANDRA-15620.svg?style=svg!|https://circleci.com/gh/spodkowinski/cassandra/tree/CASSANDRA-15620] > Add "unleveled sstables" table metric > - > > Key: CASSANDRA-15620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15620 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > The number of unleveled sstables is an important indicator that deserves to > be a dedicated table metric on its own. This will also add a global gauge > that is convenient to query. -- 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] [Updated] (CASSANDRA-15620) Add "unleveled sstables" table metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15620: --- Change Category: Operability Complexity: Low Hanging Fruit Reviewers: Chris Lohfink Status: Open (was: Triage Needed) > Add "unleveled sstables" table metric > - > > Key: CASSANDRA-15620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15620 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > The number of unleveled sstables is an important indicator that deserves to > be a dedicated table metric on its own. This will also add a global gauge > that is convenient to query. -- 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] [Created] (CASSANDRA-15620) Add "unleveled sstables" table metric
Stefan Podkowinski created CASSANDRA-15620: -- Summary: Add "unleveled sstables" table metric Key: CASSANDRA-15620 URL: https://issues.apache.org/jira/browse/CASSANDRA-15620 Project: Cassandra Issue Type: Improvement Components: Observability/Metrics Reporter: Stefan Podkowinski Assignee: Stefan Podkowinski The number of unleveled sstables is an important indicator that deserves to be a dedicated table metric on its own. This will also add a global gauge that is convenient to query. -- 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] [Updated] (CASSANDRA-15571) Change RPM repo location to downloads.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-15571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15571: --- Attachment: (was: 0001-Stop-serving-RPM-artifacts-from-www.apache.org.patch) > Change RPM repo location to downloads.apache.org > > > Key: CASSANDRA-15571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15571 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Podkowinski >Priority: Normal > > Stop serving RPM artifacts from www.apache.org as requested by INFRA. -- 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] [Updated] (CASSANDRA-15571) Change RPM repo location to downloads.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-15571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15571: --- Resolution: Won't Fix Status: Resolved (was: Open) Michael already took care of this making this patch obsolete now. > Change RPM repo location to downloads.apache.org > > > Key: CASSANDRA-15571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15571 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Podkowinski >Priority: Normal > Attachments: 0001-Stop-serving-RPM-artifacts-from-www.apache.org.patch > > > Stop serving RPM artifacts from www.apache.org as requested by INFRA. -- 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] [Updated] (CASSANDRA-15571) Change RPM repo location to downloads.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-15571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15571: --- Status: Open (was: Patch Available) > Change RPM repo location to downloads.apache.org > > > Key: CASSANDRA-15571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15571 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Podkowinski >Priority: Normal > Attachments: 0001-Stop-serving-RPM-artifacts-from-www.apache.org.patch > > > Stop serving RPM artifacts from www.apache.org as requested by INFRA. -- 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] [Updated] (CASSANDRA-15571) Change RPM repo location to downloads.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-15571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15571: --- Priority: Normal (was: Urgent) > Change RPM repo location to downloads.apache.org > > > Key: CASSANDRA-15571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15571 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Podkowinski >Priority: Normal > Attachments: 0001-Stop-serving-RPM-artifacts-from-www.apache.org.patch > > > Stop serving RPM artifacts from www.apache.org as requested by INFRA. -- 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] [Updated] (CASSANDRA-15571) Change RPM repo location to downloads.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-15571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15571: --- Test and Documentation Plan: Apply and verify Status: Patch Available (was: Open) > Change RPM repo location to downloads.apache.org > > > Key: CASSANDRA-15571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15571 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Podkowinski >Priority: Urgent > Attachments: 0001-Stop-serving-RPM-artifacts-from-www.apache.org.patch > > > Stop serving RPM artifacts from www.apache.org as requested by INFRA. -- 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] [Updated] (CASSANDRA-15571) Change RPM repo location to downloads.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-15571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15571: --- Attachment: 0001-Stop-serving-RPM-artifacts-from-www.apache.org.patch > Change RPM repo location to downloads.apache.org > > > Key: CASSANDRA-15571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15571 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Podkowinski >Priority: Urgent > Attachments: 0001-Stop-serving-RPM-artifacts-from-www.apache.org.patch > > > Stop serving RPM artifacts from www.apache.org as requested by INFRA. -- 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] [Updated] (CASSANDRA-15571) Change RPM repo location to downloads.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-15571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15571: --- Change Category: Semantic Complexity: Low Hanging Fruit Priority: Urgent (was: Normal) Status: Open (was: Triage Needed) > Change RPM repo location to downloads.apache.org > > > Key: CASSANDRA-15571 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15571 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Stefan Podkowinski >Priority: Urgent > > Stop serving RPM artifacts from www.apache.org as requested by INFRA. -- 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] [Created] (CASSANDRA-15571) Change RPM repo location to downloads.apache.org
Stefan Podkowinski created CASSANDRA-15571: -- Summary: Change RPM repo location to downloads.apache.org Key: CASSANDRA-15571 URL: https://issues.apache.org/jira/browse/CASSANDRA-15571 Project: Cassandra Issue Type: Task Components: Documentation/Website Reporter: Stefan Podkowinski Stop serving RPM artifacts from www.apache.org as requested by INFRA. -- 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-15137) Switch http to https URLs in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029150#comment-17029150 ] Stefan Podkowinski commented on CASSANDRA-15137: Can you get this committed to 2.1 [~mshuler]? maven.central turned off non-https downloads, so you won't be able to download any artifacts for that branch anymore, if they are not cached yet. > Switch http to https URLs in build.xml > -- > > Key: CASSANDRA-15137 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15137 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Normal > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: 0001-Switch-http-to-https-URLs-in-build.xml.patch, > 2.1_backport_Switch-http-to-https-URLs-in-build.xml.patch > > > Switch to using https URLs wherever possible in build.xml. -- 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] [Updated] (CASSANDRA-15467) Add missing jenkins executor requirements to CI documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15467: --- Status: Ready to Commit (was: Review In Progress) > Add missing jenkins executor requirements to CI documentation > - > > Key: CASSANDRA-15467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15467 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Michael Semb Wever >Priority: Low > > The following provides information on how to set up Jenkins CI to test > Cassandra the same as the ASF Jenkins does: > http://cassandra.apache.org/doc/latest/development/ci.html > The setup is remarkably easy, thanks [~spod]. > The only hurdle I hit was the JDK and virtualenv needs to be installed on the > executors. -- 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] [Updated] (CASSANDRA-15467) Add missing jenkins executor requirements to CI documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15467: --- Reviewers: Stefan Podkowinski, Stefan Podkowinski (was: Stefan Podkowinski) Stefan Podkowinski, Stefan Podkowinski Status: Review In Progress (was: Patch Available) > Add missing jenkins executor requirements to CI documentation > - > > Key: CASSANDRA-15467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15467 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Michael Semb Wever >Priority: Low > > The following provides information on how to set up Jenkins CI to test > Cassandra the same as the ASF Jenkins does: > http://cassandra.apache.org/doc/latest/development/ci.html > The setup is remarkably easy, thanks [~spod]. > The only hurdle I hit was the JDK and virtualenv needs to be installed on the > executors. -- 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-15467) Add missing jenkins executor requirements to CI documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008044#comment-17008044 ] Stefan Podkowinski commented on CASSANDRA-15467: Seems to be good advise, thanks! > Add missing jenkins executor requirements to CI documentation > - > > Key: CASSANDRA-15467 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15467 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Michael Semb Wever >Priority: Low > > The following provides information on how to set up Jenkins CI to test > Cassandra the same as the ASF Jenkins does: > http://cassandra.apache.org/doc/latest/development/ci.html > The setup is remarkably easy, thanks [~spod]. > The only hurdle I hit was the JDK and virtualenv needs to be installed on the > executors. -- 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-15350) Add CAS “uncertainty” and “contention" messages that are currently propagated as a WriteTimeoutException.
[
https://issues.apache.org/jira/browse/CASSANDRA-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985029#comment-16985029
]
Stefan Podkowinski commented on CASSANDRA-15350:
Just want to add some quick notes here.
First of all, the naming for {{CasWriteUncertaintyException}} could be slightly
confusing to users, since it doesn't tell you what exactly is uncertain. Also
there are situations where the write could be "uncertain" without receiving
such an exception, e.g. when the exception could not be successfully delivered
to the client and you get a client timeout instead.
How about renaming it to something like {{CasWriteStalledException}} instead?
>From the protocol change:
"_CAS_UNCERTAINTY: An exception during contended Compare And Set write/update.
The exception indicates the CAS operation result may or may not be sucessful.
Clients receiving the exception can send a read query to confirm._"
First of all, I'm not fully sure why you would want to read, instead of just
re-issuing the cas write in that case. Maybe we can change the phrasing to
something along the line of "_write was only partially completed and operation
may or may not get completed by a following CAS write or SERIAL/LOCAL_SERIAL
read_".
> Add CAS “uncertainty” and “contention" messages that are currently propagated
> as a WriteTimeoutException.
> -
>
> Key: CASSANDRA-15350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15350
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Lightweight Transactions
>Reporter: Alex Petrov
>Assignee: Yifan Cai
>Priority: Normal
> Labels: protocolv5, pull-request-available
> Attachments: Utf8StringEncodeBench.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Right now, CAS uncertainty introduced in
> https://issues.apache.org/jira/browse/CASSANDRA-6013 is propagating as
> WriteTimeout. One of this conditions it manifests is when there’s at least
> one acceptor that has accepted the value, which means that this value _may_
> still get accepted during the later round, despite the proposer failure.
> Similar problem happens with CAS contention, which is also indistinguishable
> from the “regular” timeout, even though it is visible in metrics correctly.
--
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-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981774#comment-16981774
]
Stefan Podkowinski commented on CASSANDRA-15399:
Splitting this effort into two patches would help reviewing and focusing the
discussion. I'd suggest to keep the observability patch simple and clean, and
then try to get some early feedback on potential bugs you've discovered,
tracked by a new jira. Having tests that shows existing bugs will definitely
help with that and it also would be really nice to have in-jvm distributed
tests for repairs.
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
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-15399) Add ability to track state in repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16980225#comment-16980225
]
Stefan Podkowinski commented on CASSANDRA-15399:
We could also have the coordinator send VALIDATION_REQUEST on reoccurring basis
and receive the latest status from that, instead of sending
VALIDATION_STATUS_REQ explicitly. This would allow us to resume validations, in
case the participant went down during validation and was restarted.
Haven't looked through all the proposed code changes, but impact seems to be
rather big for an observability patch. I think it will be convenient for users
to be able to query repair state, but we should keep a good balance between
value from that and potential regressions.
> Add ability to track state in repair
>
>
> Key: CASSANDRA-15399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15399
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To enhance the visibility in repair, we should expose internal state via
> virtual tables; the state should include coordinator as well as participant
> state (validation, sync, etc.)
> I propose the following tables:
> repairs - high level summary of the global state of repair; this should be
> called on the coordinator.
> {code:sql}
> CREATE TABLE repairs (
> id uuid,
> keyspace_name text,
> table_names frozen>,
> ranges frozen>,
> coordinator text,
> participants frozen>,
> state text,
> progress_percentage float,
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id) )
> )
> {code}
> repair_tasks - represents RepairJob and participants state. This will show
> if validations are running on participants and the progress they are making;
> this should be called on the coordinator.
> {code:sql}
> CREATE TABLE repair_tasks (
> id uuid,
> session_id uuid,
> keyspace_name text,
> table_name text,
> ranges frozen>,
> coordinator text,
> participant text,
> state text,
> state_description text,
> progress_percentage float, -- between 0.0 and 100.0
> last_updated_at_millis bigint,
> duration_micro bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name, participant )
> )
> {code}
> repair_validations - shows the state of the validation task and updated
> periodically while validation is running; this should be called on the
> participants.
> {code:sql}
> CREATE TABLE repair_validations (
> id uuid,
> session_id uuid,
> ranges frozen>,
> keyspace_name text,
> table_name text,
> initiator text,
> state text,
> progress_percentage float,
> queue_duration_ms bigint,
> runtime_duration_ms bigint,
> total_duration_ms bigint,
> estimated_partitions bigint,
> partitions_processed bigint,
> estimated_total_bytes bigint,
> failure_cause text,
> PRIMARY KEY ( (id), session_id, table_name )
> )
> {code}
> The main reason for exposing virtual tables rather than exposing through
> durable tables is to make sure what is exposed is accurate. In cases of
> write failures or node failures, the durable tables could become in-accurate
> and could add edge cases where the repair is not running but the tables say
> it is; by relying on repair's internal in-memory bookkeeping, these problems
> go away.
> This jira does not try to solve the following:
> 1) repair resiliency - there are edge cases where repair hits an error and
> runs forever (at least from nodetool's perspective).
> 2) repair stream tracking - I have not learned the streaming side yet and
> what I see is multiple implementations exist, so seems like high scope. My
> hope is to punt from this jira and tackle separately.
--
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] [Updated] (CASSANDRA-15289) bad merge reverted CASSANDRA-14993
[ https://issues.apache.org/jira/browse/CASSANDRA-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15289: --- Status: Ready to Commit (was: Review In Progress) LGTM, that's what went in with CASSANDRA-14993 > bad merge reverted CASSANDRA-14993 > -- > > Key: CASSANDRA-15289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15289 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > -- 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] [Updated] (CASSANDRA-15289) bad merge reverted CASSANDRA-14993
[ https://issues.apache.org/jira/browse/CASSANDRA-15289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15289: --- Reviewers: Stefan Podkowinski, Stefan Podkowinski (was: Stefan Podkowinski) Stefan Podkowinski, Stefan Podkowinski (was: Stefan Podkowinski) Status: Review In Progress (was: Patch Available) > bad merge reverted CASSANDRA-14993 > -- > > Key: CASSANDRA-15289 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15289 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > -- 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=16871740#comment-16871740 ] Stefan Podkowinski commented on CASSANDRA-10190: I was just trying to catch up, so please correct me if I'm wrong. So we're adding 1) Python 3 support for cqlshlib and tests 2) fix tests in cqlshlib/test but don't actually run them on CI (will be done in CASSANDRA-14990) 3) fix and enable remaining cqlsh dtest leftovers from CASSANDRA-14298 with dependency to cqlshlib. Current branches are https://github.com/ptbannister/cassandra/tree/10190-rebase-20190609 https://github.com/ptbannister/cassandra-dtest/commits/cqlshlib6-rebase-20190322 > 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-15143) Remove assertion on file deletion to trigger failure policy
[ https://issues.apache.org/jira/browse/CASSANDRA-15143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15143: --- Test and Documentation Plan: [Tests|https://circleci.com/gh/spodkowinski/workflows/cassandra/tree/CASSANDRA-15143] Status: Patch Available (was: Open) > Remove assertion on file deletion to trigger failure policy > --- > > Key: CASSANDRA-15143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15143 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Deleting any files by using FileUtils.deleteWithConfirm() will involve > checking for file existence using an assertion. If the assertion passes, any > errors from the actual Files.delete() operation will get handled as a > FSWriteError and invoke the DiskFailurePolicy. This will get us to a > situation where only some cases of bad FS or disk issues will be handed by > the DFP, while FS issues that may already cause the file.exists() assertion > to fail, will only manifest as AssertionErrors. We should invoke DFP for the > later as well and remove the assertion altogether. -- 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-15143) Remove assertion on file deletion to trigger failure policy
[ https://issues.apache.org/jira/browse/CASSANDRA-15143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849604#comment-16849604 ] Stefan Podkowinski commented on CASSANDRA-15143: * [CASSANDRA-15143|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-15143] * [Tests|https://circleci.com/gh/spodkowinski/workflows/cassandra/tree/CASSANDRA-15143] > Remove assertion on file deletion to trigger failure policy > --- > > Key: CASSANDRA-15143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15143 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Deleting any files by using FileUtils.deleteWithConfirm() will involve > checking for file existence using an assertion. If the assertion passes, any > errors from the actual Files.delete() operation will get handled as a > FSWriteError and invoke the DiskFailurePolicy. This will get us to a > situation where only some cases of bad FS or disk issues will be handed by > the DFP, while FS issues that may already cause the file.exists() assertion > to fail, will only manifest as AssertionErrors. We should invoke DFP for the > later as well and remove the assertion altogether. -- 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-15143) Remove assertion on file deletion to trigger failure policy
[ https://issues.apache.org/jira/browse/CASSANDRA-15143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-15143: --- Severity: Normal Complexity: Low Hanging Fruit Discovered By: User Report Bug Category: Parent values: Correctness(12982) Component/s: Local/SSTable Status: Open (was: Triage Needed) > Remove assertion on file deletion to trigger failure policy > --- > > Key: CASSANDRA-15143 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15143 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Deleting any files by using FileUtils.deleteWithConfirm() will involve > checking for file existence using an assertion. If the assertion passes, any > errors from the actual Files.delete() operation will get handled as a > FSWriteError and invoke the DiskFailurePolicy. This will get us to a > situation where only some cases of bad FS or disk issues will be handed by > the DFP, while FS issues that may already cause the file.exists() assertion > to fail, will only manifest as AssertionErrors. We should invoke DFP for the > later as well and remove the assertion altogether. -- 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-15143) Remove assertion on file deletion to trigger failure policy
Stefan Podkowinski created CASSANDRA-15143: -- Summary: Remove assertion on file deletion to trigger failure policy Key: CASSANDRA-15143 URL: https://issues.apache.org/jira/browse/CASSANDRA-15143 Project: Cassandra Issue Type: Bug Reporter: Stefan Podkowinski Assignee: Stefan Podkowinski Deleting any files by using FileUtils.deleteWithConfirm() will involve checking for file existence using an assertion. If the assertion passes, any errors from the actual Files.delete() operation will get handled as a FSWriteError and invoke the DiskFailurePolicy. This will get us to a situation where only some cases of bad FS or disk issues will be handed by the DFP, while FS issues that may already cause the file.exists() assertion to fail, will only manifest as AssertionErrors. We should invoke DFP for the later as well and remove the assertion altogether. -- 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-15142) Fix errors on repairing empty keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15142:
---
Test and Documentation Plan:
[CircleCI|https://circleci.com/workflow-run/45ecd7af-ec77-4090-bf07-278c78e43e30]
(was: *
[CASSANDRA-15142|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-15142]
*
[CircleCI|https://circleci.com/workflow-run/45ecd7af-ec77-4090-bf07-278c78e43e30])
> Fix errors on repairing empty keyspace
> --
>
> Key: CASSANDRA-15142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Tool/nodetool
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> Running repairs on empty keyspaces will produce a rather confusing error in
> trunk:
> {noformat}
> ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 -
> Repair 014607d0-7dff-11e9-9256-158db058ccc5 failed:
> java.lang.IllegalArgumentException: repair sessions cannot operate on
> multiple keyspaces
> ▸ at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
> ▸ at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
> ▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ▸ at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ▸ at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Let's ignore empty keyspaces and return a success return status instead.
--
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-15142) Fix errors on repairing empty keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849001#comment-16849001
]
Stefan Podkowinski commented on CASSANDRA-15142:
*
[CASSANDRA-15142|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-15142]
*
[CircleCI|https://circleci.com/workflow-run/45ecd7af-ec77-4090-bf07-278c78e43e30]
> Fix errors on repairing empty keyspace
> --
>
> Key: CASSANDRA-15142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Tool/nodetool
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> Running repairs on empty keyspaces will produce a rather confusing error in
> trunk:
> {noformat}
> ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 -
> Repair 014607d0-7dff-11e9-9256-158db058ccc5 failed:
> java.lang.IllegalArgumentException: repair sessions cannot operate on
> multiple keyspaces
> ▸ at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
> ▸ at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
> ▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ▸ at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ▸ at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Let's ignore empty keyspaces and return a success return status instead.
--
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-15142) Fix errors on repairing empty keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15142:
---
Test and Documentation Plan:
*
[CASSANDRA-15142|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-15142]
*
[CircleCI|https://circleci.com/workflow-run/45ecd7af-ec77-4090-bf07-278c78e43e30]
Status: Patch Available (was: Open)
> Fix errors on repairing empty keyspace
> --
>
> Key: CASSANDRA-15142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Tool/nodetool
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> Running repairs on empty keyspaces will produce a rather confusing error in
> trunk:
> {noformat}
> ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 -
> Repair 014607d0-7dff-11e9-9256-158db058ccc5 failed:
> java.lang.IllegalArgumentException: repair sessions cannot operate on
> multiple keyspaces
> ▸ at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
> ▸ at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
> ▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ▸ at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ▸ at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Let's ignore empty keyspaces and return a success return status instead.
--
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-15142) Fix errors on repairing empty keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-15142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15142:
---
Severity: Low
Complexity: Low Hanging Fruit
Discovered By: User Report
Bug Category: Parent values: Correctness(12982)Level 1 values: Semantic
Failure(12988)
Status: Open (was: Triage Needed)
> Fix errors on repairing empty keyspace
> --
>
> Key: CASSANDRA-15142
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Tool/nodetool
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> Running repairs on empty keyspaces will produce a rather confusing error in
> trunk:
> {noformat}
> ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 -
> Repair 014607d0-7dff-11e9-9256-158db058ccc5 failed:
> java.lang.IllegalArgumentException: repair sessions cannot operate on
> multiple keyspaces
> ▸ at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
> ▸ at
> org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
> ▸ at
> org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
> ▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> ▸ at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> ▸ at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ▸ at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Let's ignore empty keyspaces and return a success return status instead.
--
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-15142) Fix errors on repairing empty keyspace
Stefan Podkowinski created CASSANDRA-15142:
--
Summary: Fix errors on repairing empty keyspace
Key: CASSANDRA-15142
URL: https://issues.apache.org/jira/browse/CASSANDRA-15142
Project: Cassandra
Issue Type: Bug
Components: Consistency/Repair, Tool/nodetool
Reporter: Stefan Podkowinski
Assignee: Stefan Podkowinski
Running repairs on empty keyspaces will produce a rather confusing error in
trunk:
{noformat}
ERROR [Repair-Task:1] 2019-05-24 10:36:20,323 RepairRunnable.java:274 - Repair
014607d0-7dff-11e9-9256-158db058ccc5 failed:
java.lang.IllegalArgumentException: repair sessions cannot operate on multiple
keyspaces
▸ at com.google.common.base.Preconditions.checkArgument(Preconditions.java:135)
▸ at
org.apache.cassandra.service.ActiveRepairService$ParentRepairSession.(ActiveRepairService.java:566)
▸ at
org.apache.cassandra.service.ActiveRepairService.registerParentRepairSession(ActiveRepairService.java:484)
▸ at
org.apache.cassandra.service.ActiveRepairService.prepareForRepair(ActiveRepairService.java:395)
▸ at
org.apache.cassandra.repair.RepairRunnable.runMayThrow(RepairRunnable.java:269)
▸ at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
▸ at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
▸ at java.util.concurrent.FutureTask.run(FutureTask.java:266)
▸ at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
▸ at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
▸ at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
▸ at java.lang.Thread.run(Thread.java:748)
{noformat}
Let's ignore empty keyspaces and return a success return status instead.
--
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=16845256#comment-16845256 ] Stefan Podkowinski commented on CASSANDRA-10190: I'm a bit busy at the moment, but will try to have a look. It's interesting to see that you've added docker support for running tests with bare py2/py3 installations. Maybe we can integrate that with circleci. > 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-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16792901#comment-16792901
]
Stefan Podkowinski commented on CASSANDRA-14806:
Looks like your latest builds can be found at:
* [2.2|https://circleci.com/workflow-run/6ac9d6c4-3968-4a6e-8cbe-cad8c7880961]
* [3.0|https://circleci.com/workflow-run/50120c8c-8641-4761-aaa2-64214ed9290a]
* [3.11|https://circleci.com/workflow-run/db5e3bb2-4b8a-456a-8d5b-6dc943fea0fe]
*
[trunk|https://circleci.com/workflow-run/e1eec049-70f1-4a07-b3e9-1c519cb26888]
There seems to be a significant number of 2.2 dtests (see also CASSANDRA-14866)
and the upgrade tests failing, so I did some reference runs against the
unmodified branches. Turns out we see the same kind of failures there as well,
so it shouldn't be related to the patch at all.
* [3.0 - upgrade
tests|https://circleci.com/gh/spodkowinski/cassandra/675#tests/containers/11]
* [3.11 - upgrade
tests|https://circleci.com/gh/spodkowinski/cassandra/673#tests/containers/11]
* [2.2 -
dtests|https://circleci.com/workflow-run/0dae4fa9-7b00-4814-9726-87ad513bb110]
+1, I think we're ready to get this merged now.
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Normal
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
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=16790996#comment-16790996 ] Stefan Podkowinski commented on CASSANDRA-14298: You to be clear, I was referring to [d724c125|https://github.com/apache/cassandra-dtest/pull/45/commits/d724c1257ab4cf2428a62ff8a77d9d1265b03cba] as "Hack debugging". > 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: Normal > 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=16790868#comment-16790868 ] Stefan Podkowinski commented on CASSANDRA-14298: We should be fine merging the dtest changes (sans "Hack debugging") if tests are passing and do not take a huge amount of time, which doesn't seem to be the case. > 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: Normal > 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=16789240#comment-16789240 ] Stefan Podkowinski commented on CASSANDRA-14298: I was hopping we'd be able to run the separate build with low resources settings, so Patrick and others would be able to run tests own their own in CircleCI. Also can you link the branches you want me to look at? > 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=16788973#comment-16788973 ] Stefan Podkowinski commented on CASSANDRA-14298: I'll have a look next week. I also hope we'll be able to commit CASSANDRA-14806 by then and we can break this out as separate build/test target. > 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-15012) token_generator_test.TestTokenGenerator test fails on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783822#comment-16783822
]
Stefan Podkowinski commented on CASSANDRA-15012:
+1
> token_generator_test.TestTokenGenerator test fails on 2.2
> -
>
> Key: CASSANDRA-15012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15012
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: beginner, dtest, test
> Fix For: 2.2.x
>
> Attachments: --graph output.png, test-output.png
>
>
> While running tests for the 2.2.14 candidate I noticed that the
> {{TestTokenGenerator}} dtests are broken. I reproduced locally as well, the
> issue appears to be that we're running a python2 script with python3 (since
> dtests run python3 now).
> Should be a quick fix to make the token generator script py2/3 compatible.
> Example local run:
> {noformat}
> pytest --cassandra-dir=/home/josephl/pg/cassandra_2 -k TestTokenGenerator
>
> 1 ↵
> ===
> test session starts
>
> platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
> rootdir: /home/josephl/pg/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.3.3, flaky-3.4.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 1028 items / 1025 deselected
>
>
>
> token_generator_test.py FFF
>
>
>[100%]
> =
> FAILURES
> =
> _
> TestTokenGenerator.test_multi_dc_tokens_default
> __
> self =
> def test_multi_dc_tokens_default(self):
> > self._multi_dc_tokens()
> token_generator_test.py:167:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> token_generator_test.py:153: in _multi_dc_tokens
> generated_tokens =
> self.call_token_generator(self.cluster.get_install_dir(), random, dc_nodes)
> token_generator_test.py:43: in call_token_generator
> token_gen_output = subprocess.check_output(args)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> input = None, timeout = None, check = True, popenargs =
> (['/home/josephl/pg/cassandra_2/tools/bin/token-generator', '3', '5'],),
> kwargs = {'stdout': -1}, process = 0x7f5188b80208>, stdout = b'', stderr = None
> retcode = 1
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default, stdout and stderr are not captured, and those
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
> them.
>
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the
> return code
> in the returncode attribute, and output & stderr attributes if those
> streams
> were captured.
>
> If timeout is given, and the process takes too long, a TimeoutExpired
> exception will be raised.
>
>
[jira] [Updated] (CASSANDRA-15012) token_generator_test.TestTokenGenerator test fails on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15012:
---
Status: In Progress (was: Ready to Commit)
> token_generator_test.TestTokenGenerator test fails on 2.2
> -
>
> Key: CASSANDRA-15012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15012
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: beginner, dtest, test
> Fix For: 2.2.x
>
> Attachments: --graph output.png, test-output.png
>
>
> While running tests for the 2.2.14 candidate I noticed that the
> {{TestTokenGenerator}} dtests are broken. I reproduced locally as well, the
> issue appears to be that we're running a python2 script with python3 (since
> dtests run python3 now).
> Should be a quick fix to make the token generator script py2/3 compatible.
> Example local run:
> {noformat}
> pytest --cassandra-dir=/home/josephl/pg/cassandra_2 -k TestTokenGenerator
>
> 1 ↵
> ===
> test session starts
>
> platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
> rootdir: /home/josephl/pg/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.3.3, flaky-3.4.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 1028 items / 1025 deselected
>
>
>
> token_generator_test.py FFF
>
>
>[100%]
> =
> FAILURES
> =
> _
> TestTokenGenerator.test_multi_dc_tokens_default
> __
> self =
> def test_multi_dc_tokens_default(self):
> > self._multi_dc_tokens()
> token_generator_test.py:167:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> token_generator_test.py:153: in _multi_dc_tokens
> generated_tokens =
> self.call_token_generator(self.cluster.get_install_dir(), random, dc_nodes)
> token_generator_test.py:43: in call_token_generator
> token_gen_output = subprocess.check_output(args)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> input = None, timeout = None, check = True, popenargs =
> (['/home/josephl/pg/cassandra_2/tools/bin/token-generator', '3', '5'],),
> kwargs = {'stdout': -1}, process = 0x7f5188b80208>, stdout = b'', stderr = None
> retcode = 1
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default, stdout and stderr are not captured, and those
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
> them.
>
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the
> return code
> in the returncode attribute, and output & stderr attributes if those
> streams
> were captured.
>
> If timeout is given, and the process takes too long, a TimeoutExpired
> exception will be raised.
>
>
[jira] [Commented] (CASSANDRA-15012) token_generator_test.TestTokenGenerator test fails on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783627#comment-16783627
]
Stefan Podkowinski commented on CASSANDRA-15012:
Patch looks good. This is only 2.2? I think we removed that tool in 3.0..
> token_generator_test.TestTokenGenerator test fails on 2.2
> -
>
> Key: CASSANDRA-15012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15012
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: beginner, dtest, test
> Fix For: 2.2.x
>
> Attachments: --graph output.png, test-output.png
>
>
> While running tests for the 2.2.14 candidate I noticed that the
> {{TestTokenGenerator}} dtests are broken. I reproduced locally as well, the
> issue appears to be that we're running a python2 script with python3 (since
> dtests run python3 now).
> Should be a quick fix to make the token generator script py2/3 compatible.
> Example local run:
> {noformat}
> pytest --cassandra-dir=/home/josephl/pg/cassandra_2 -k TestTokenGenerator
>
> 1 ↵
> ===
> test session starts
>
> platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
> rootdir: /home/josephl/pg/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.3.3, flaky-3.4.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 1028 items / 1025 deselected
>
>
>
> token_generator_test.py FFF
>
>
>[100%]
> =
> FAILURES
> =
> _
> TestTokenGenerator.test_multi_dc_tokens_default
> __
> self =
> def test_multi_dc_tokens_default(self):
> > self._multi_dc_tokens()
> token_generator_test.py:167:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> token_generator_test.py:153: in _multi_dc_tokens
> generated_tokens =
> self.call_token_generator(self.cluster.get_install_dir(), random, dc_nodes)
> token_generator_test.py:43: in call_token_generator
> token_gen_output = subprocess.check_output(args)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> input = None, timeout = None, check = True, popenargs =
> (['/home/josephl/pg/cassandra_2/tools/bin/token-generator', '3', '5'],),
> kwargs = {'stdout': -1}, process = 0x7f5188b80208>, stdout = b'', stderr = None
> retcode = 1
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default, stdout and stderr are not captured, and those
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
> them.
>
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the
> return code
> in the returncode attribute, and output & stderr attributes if those
> streams
> were captured.
>
> If timeout is given, and the process takes too
[jira] [Updated] (CASSANDRA-15012) token_generator_test.TestTokenGenerator test fails on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15012:
---
Status: Ready to Commit (was: Patch Available)
> token_generator_test.TestTokenGenerator test fails on 2.2
> -
>
> Key: CASSANDRA-15012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15012
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: beginner, dtest, test
> Fix For: 2.2.x
>
> Attachments: --graph output.png, test-output.png
>
>
> While running tests for the 2.2.14 candidate I noticed that the
> {{TestTokenGenerator}} dtests are broken. I reproduced locally as well, the
> issue appears to be that we're running a python2 script with python3 (since
> dtests run python3 now).
> Should be a quick fix to make the token generator script py2/3 compatible.
> Example local run:
> {noformat}
> pytest --cassandra-dir=/home/josephl/pg/cassandra_2 -k TestTokenGenerator
>
> 1 ↵
> ===
> test session starts
>
> platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
> rootdir: /home/josephl/pg/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.3.3, flaky-3.4.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 1028 items / 1025 deselected
>
>
>
> token_generator_test.py FFF
>
>
>[100%]
> =
> FAILURES
> =
> _
> TestTokenGenerator.test_multi_dc_tokens_default
> __
> self =
> def test_multi_dc_tokens_default(self):
> > self._multi_dc_tokens()
> token_generator_test.py:167:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> token_generator_test.py:153: in _multi_dc_tokens
> generated_tokens =
> self.call_token_generator(self.cluster.get_install_dir(), random, dc_nodes)
> token_generator_test.py:43: in call_token_generator
> token_gen_output = subprocess.check_output(args)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> input = None, timeout = None, check = True, popenargs =
> (['/home/josephl/pg/cassandra_2/tools/bin/token-generator', '3', '5'],),
> kwargs = {'stdout': -1}, process = 0x7f5188b80208>, stdout = b'', stderr = None
> retcode = 1
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default, stdout and stderr are not captured, and those
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
> them.
>
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the
> return code
> in the returncode attribute, and output & stderr attributes if those
> streams
> were captured.
>
> If timeout is given, and the process takes too long, a TimeoutExpired
> exception will be raised.
>
[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4
[
https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777972#comment-16777972
]
Stefan Podkowinski commented on CASSANDRA-9384:
---
Looks like you added the following text to NEWS.txt:
{quote}Before you upgrade, confirm that
`cassandra.auth_bcrypt_gensalt_log2_rounds` property
is set to value lower than 31 otherwise Cassandra will fail to start.
See CASSANDRA-9384
for further details.{quote}
First of all, there's no such property in the conf or bin files, so it will
most likely leave users confused and some may even think they have to add this
property, in case it isn't set yet.
Also, what happens to existing hashes with 31 rounds? Upgrading to 0.4 will
make all authentication attempts fail, see my first comment in thread. Changing
the property will not solve this.
> Update jBCrypt dependency to version 0.4
>
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.
--
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-15027) Handle IR prepare phase failures less race prone by waiting for all results
[
https://issues.apache.org/jira/browse/CASSANDRA-15027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15027:
---
Fix Version/s: (was: 4.x)
4.0
> Handle IR prepare phase failures less race prone by waiting for all results
> ---
>
> Key: CASSANDRA-15027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15027
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.0
>
>
> Handling incremental repairs as a coordinator begins by sending a
> {{PrepareConsistentRequest}} message to all participants, which may also
> include the coordinator itself. Participants will run anti-compactions upon
> receiving such a message and report the result of the operation back to the
> coordinator.
> Once we receive a failure response from any of the participants, we fail-fast
> in {{CoordinatorSession.handlePrepareResponse()}}, which will in turn
> completes the {{prepareFuture}} that {{RepairRunnable}} is blocking on. Then
> the repair command will terminate with an error status, as expected.
> The issue is that in case the node will both be coordinator and participant,
> we may end up with a local session and submitted anti-compactions, which will
> be executed without any coordination with the coordinator session (on same
> node). This may result in situations where running repair commands right
> after another, may cause overlapping execution of anti-compactions that will
> cause the following (misleading) message to show up in the logs and will
> cause the repair to fail again:
> "Prepare phase for incremental repair session %s has failed because it
> encountered intersecting sstables belonging to another incremental repair
> session (%s). This is by starting an incremental repair session before a
> previous one has completed. Check nodetool repair_admin for hung sessions and
> fix them."
--
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-15027) Handle IR prepare phase failures less race prone by waiting for all results
[
https://issues.apache.org/jira/browse/CASSANDRA-15027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775437#comment-16775437
]
Stefan Podkowinski commented on CASSANDRA-15027:
LGTM +1
> Handle IR prepare phase failures less race prone by waiting for all results
> ---
>
> Key: CASSANDRA-15027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15027
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> Handling incremental repairs as a coordinator begins by sending a
> {{PrepareConsistentRequest}} message to all participants, which may also
> include the coordinator itself. Participants will run anti-compactions upon
> receiving such a message and report the result of the operation back to the
> coordinator.
> Once we receive a failure response from any of the participants, we fail-fast
> in {{CoordinatorSession.handlePrepareResponse()}}, which will in turn
> completes the {{prepareFuture}} that {{RepairRunnable}} is blocking on. Then
> the repair command will terminate with an error status, as expected.
> The issue is that in case the node will both be coordinator and participant,
> we may end up with a local session and submitted anti-compactions, which will
> be executed without any coordination with the coordinator session (on same
> node). This may result in situations where running repair commands right
> after another, may cause overlapping execution of anti-compactions that will
> cause the following (misleading) message to show up in the logs and will
> cause the repair to fail again:
> "Prepare phase for incremental repair session %s has failed because it
> encountered intersecting sstables belonging to another incremental repair
> session (%s). This is by starting an incremental repair session before a
> previous one has completed. Check nodetool repair_admin for hung sessions and
> fix them."
--
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-15027) Handle IR prepare phase failures less race prone by waiting for all results
[
https://issues.apache.org/jira/browse/CASSANDRA-15027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775178#comment-16775178
]
Stefan Podkowinski edited comment on CASSANDRA-15027 at 2/22/19 4:03 PM:
-
Your updates look like valuable improvement over the initial patch. I'm +1 in
general as for the changes, but also fixed some additional minor issues and
added a new tests:
*
[CASSANDRA-15027|https://github.com/spodkowinski/cassandra/commits/CASSANDRA-15027]
* [https://circleci.com/workflow-run/2b444c33-a54c-46b5-9923-bcded8bcf465]
Please see comments with each commit in branch above for details.
Also happy to discuss any of the changes (most likely the last commit) in
another jira, if you feel it's out of scope for this ticket.
was (Author: spo...@gmail.com):
Your updates look like valuable improvement over the initial patch. I'm +1 in
general as for the changes, but also fixed some additional minor issues and
added a new tests:
*
[CASSANDRA-15027|https://github.com/spodkowinski/cassandra/commits/CASSANDRA-15027]
* [circleci|https://circleci.com/gh/spodkowinski/cassandra/653]
Please see comments with each commit in branch above for details.
Also happy to discuss any of the changes (most likely the last commit) in
another jira, if you feel it's out of scope for this ticket.
> Handle IR prepare phase failures less race prone by waiting for all results
> ---
>
> Key: CASSANDRA-15027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15027
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> Handling incremental repairs as a coordinator begins by sending a
> {{PrepareConsistentRequest}} message to all participants, which may also
> include the coordinator itself. Participants will run anti-compactions upon
> receiving such a message and report the result of the operation back to the
> coordinator.
> Once we receive a failure response from any of the participants, we fail-fast
> in {{CoordinatorSession.handlePrepareResponse()}}, which will in turn
> completes the {{prepareFuture}} that {{RepairRunnable}} is blocking on. Then
> the repair command will terminate with an error status, as expected.
> The issue is that in case the node will both be coordinator and participant,
> we may end up with a local session and submitted anti-compactions, which will
> be executed without any coordination with the coordinator session (on same
> node). This may result in situations where running repair commands right
> after another, may cause overlapping execution of anti-compactions that will
> cause the following (misleading) message to show up in the logs and will
> cause the repair to fail again:
> "Prepare phase for incremental repair session %s has failed because it
> encountered intersecting sstables belonging to another incremental repair
> session (%s). This is by starting an incremental repair session before a
> previous one has completed. Check nodetool repair_admin for hung sessions and
> fix them."
--
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-15027) Handle IR prepare phase failures less race prone by waiting for all results
[
https://issues.apache.org/jira/browse/CASSANDRA-15027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16775178#comment-16775178
]
Stefan Podkowinski commented on CASSANDRA-15027:
Your updates look like valuable improvement over the initial patch. I'm +1 in
general as for the changes, but also fixed some additional minor issues and
added a new tests:
*
[CASSANDRA-15027|https://github.com/spodkowinski/cassandra/commits/CASSANDRA-15027]
* [circleci|https://circleci.com/gh/spodkowinski/cassandra/653]
Please see comments with each commit in branch above for details.
Also happy to discuss any of the changes (most likely the last commit) in
another jira, if you feel it's out of scope for this ticket.
> Handle IR prepare phase failures less race prone by waiting for all results
> ---
>
> Key: CASSANDRA-15027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15027
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> Handling incremental repairs as a coordinator begins by sending a
> {{PrepareConsistentRequest}} message to all participants, which may also
> include the coordinator itself. Participants will run anti-compactions upon
> receiving such a message and report the result of the operation back to the
> coordinator.
> Once we receive a failure response from any of the participants, we fail-fast
> in {{CoordinatorSession.handlePrepareResponse()}}, which will in turn
> completes the {{prepareFuture}} that {{RepairRunnable}} is blocking on. Then
> the repair command will terminate with an error status, as expected.
> The issue is that in case the node will both be coordinator and participant,
> we may end up with a local session and submitted anti-compactions, which will
> be executed without any coordination with the coordinator session (on same
> node). This may result in situations where running repair commands right
> after another, may cause overlapping execution of anti-compactions that will
> cause the following (misleading) message to show up in the logs and will
> cause the repair to fail again:
> "Prepare phase for incremental repair session %s has failed because it
> encountered intersecting sstables belonging to another incremental repair
> session (%s). This is by starting an incremental repair session before a
> previous one has completed. Check nodetool repair_admin for hung sessions and
> fix them."
--
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-9384) Update jBCrypt dependency to version 0.4
[ https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16773283#comment-16773283 ] Stefan Podkowinski commented on CASSANDRA-9384: --- We don't need to "grab attention" by having C* fail to start. We should put whats important for upgrades into NEWS.txt. So how about having that warning message and put a notice there, saying something like "check your log2_rounds settings if you're seeing the following message during startup". The user can then deliberately make the decision to change or ignore the setting. > Update jBCrypt dependency to version 0.4 > > > Key: CASSANDRA-9384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9384 > Project: Cassandra > Issue Type: Bug >Reporter: Sam Tunnicliffe >Assignee: Dinesh Joshi >Priority: Major > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x > > > https://bugzilla.mindrot.org/show_bug.cgi?id=2097 > Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 > indicate that this is now fixed, so we should update. > Thanks to [~Bereng] for identifying the issue. -- 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-9384) Update jBCrypt dependency to version 0.4
[ https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772943#comment-16772943 ] Stefan Podkowinski commented on CASSANDRA-9384: --- The bcrypt dependency should not be updated in any version but trunk in that case. The idea is to give users time to migrate to the new setting, without causing an incident during upgrades. > Update jBCrypt dependency to version 0.4 > > > Key: CASSANDRA-9384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9384 > Project: Cassandra > Issue Type: Bug >Reporter: Sam Tunnicliffe >Assignee: Dinesh Joshi >Priority: Major > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x > > > https://bugzilla.mindrot.org/show_bug.cgi?id=2097 > Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 > indicate that this is now fixed, so we should update. > Thanks to [~Bereng] for identifying the issue. -- 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-15012) token_generator_test.TestTokenGenerator test fails on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772090#comment-16772090
]
Stefan Podkowinski commented on CASSANDRA-15012:
{noformat}
python2.7 tools/bin/token-generator
Traceback (most recent call last):
File "tools/bin/token-generator", line 22, in
from builtins import input
ImportError: No module named builtins
{noformat}
I think you'd have to install the future package for that?
> token_generator_test.TestTokenGenerator test fails on 2.2
> -
>
> Key: CASSANDRA-15012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15012
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: beginner, dtest, test
> Fix For: 2.2.x
>
> Attachments: --graph output.png, test-output.png
>
>
> While running tests for the 2.2.14 candidate I noticed that the
> {{TestTokenGenerator}} dtests are broken. I reproduced locally as well, the
> issue appears to be that we're running a python2 script with python3 (since
> dtests run python3 now).
> Should be a quick fix to make the token generator script py2/3 compatible.
> Example local run:
> {noformat}
> pytest --cassandra-dir=/home/josephl/pg/cassandra_2 -k TestTokenGenerator
>
> 1 ↵
> ===
> test session starts
>
> platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
> rootdir: /home/josephl/pg/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.3.3, flaky-3.4.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 1028 items / 1025 deselected
>
>
>
> token_generator_test.py FFF
>
>
>[100%]
> =
> FAILURES
> =
> _
> TestTokenGenerator.test_multi_dc_tokens_default
> __
> self =
> def test_multi_dc_tokens_default(self):
> > self._multi_dc_tokens()
> token_generator_test.py:167:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> token_generator_test.py:153: in _multi_dc_tokens
> generated_tokens =
> self.call_token_generator(self.cluster.get_install_dir(), random, dc_nodes)
> token_generator_test.py:43: in call_token_generator
> token_gen_output = subprocess.check_output(args)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> input = None, timeout = None, check = True, popenargs =
> (['/home/josephl/pg/cassandra_2/tools/bin/token-generator', '3', '5'],),
> kwargs = {'stdout': -1}, process = 0x7f5188b80208>, stdout = b'', stderr = None
> retcode = 1
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default, stdout and stderr are not captured, and those
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
> them.
>
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the
[jira] [Commented] (CASSANDRA-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770954#comment-16770954
]
Stefan Podkowinski commented on CASSANDRA-14806:
Doing a test run using the docker image mentioned above will finish in a bit
less than an hour:
https://circleci.com/gh/spodkowinski/cassandra/652
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
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-15027) Handle IR prepare phase failures less race prone by waiting for all results
[
https://issues.apache.org/jira/browse/CASSANDRA-15027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15027:
---
Status: Patch Available (was: Open)
> Handle IR prepare phase failures less race prone by waiting for all results
> ---
>
> Key: CASSANDRA-15027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15027
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> Handling incremental repairs as a coordinator begins by sending a
> {{PrepareConsistentRequest}} message to all participants, which may also
> include the coordinator itself. Participants will run anti-compactions upon
> receiving such a message and report the result of the operation back to the
> coordinator.
> Once we receive a failure response from any of the participants, we fail-fast
> in {{CoordinatorSession.handlePrepareResponse()}}, which will in turn
> completes the {{prepareFuture}} that {{RepairRunnable}} is blocking on. Then
> the repair command will terminate with an error status, as expected.
> The issue is that in case the node will both be coordinator and participant,
> we may end up with a local session and submitted anti-compactions, which will
> be executed without any coordination with the coordinator session (on same
> node). This may result in situations where running repair commands right
> after another, may cause overlapping execution of anti-compactions that will
> cause the following (misleading) message to show up in the logs and will
> cause the repair to fail again:
> "Prepare phase for incremental repair session %s has failed because it
> encountered intersecting sstables belonging to another incremental repair
> session (%s). This is by starting an incremental repair session before a
> previous one has completed. Check nodetool repair_admin for hung sessions and
> fix them."
--
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-15027) Handle IR prepare phase failures less race prone by waiting for all results
[
https://issues.apache.org/jira/browse/CASSANDRA-15027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770869#comment-16770869
]
Stefan Podkowinski commented on CASSANDRA-15027:
* [ [trunk|https://github.com/spodkowinski/cassandra/tree/CASSANDRA-15027] ][
[circleci|https://circleci.com/workflow-run/2b027f87-cf45-48ee-8eae-45a563701bc6]
]
> Handle IR prepare phase failures less race prone by waiting for all results
> ---
>
> Key: CASSANDRA-15027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15027
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Local/Compaction
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
> Fix For: 4.x
>
>
> Handling incremental repairs as a coordinator begins by sending a
> {{PrepareConsistentRequest}} message to all participants, which may also
> include the coordinator itself. Participants will run anti-compactions upon
> receiving such a message and report the result of the operation back to the
> coordinator.
> Once we receive a failure response from any of the participants, we fail-fast
> in {{CoordinatorSession.handlePrepareResponse()}}, which will in turn
> completes the {{prepareFuture}} that {{RepairRunnable}} is blocking on. Then
> the repair command will terminate with an error status, as expected.
> The issue is that in case the node will both be coordinator and participant,
> we may end up with a local session and submitted anti-compactions, which will
> be executed without any coordination with the coordinator session (on same
> node). This may result in situations where running repair commands right
> after another, may cause overlapping execution of anti-compactions that will
> cause the following (misleading) message to show up in the logs and will
> cause the repair to fail again:
> "Prepare phase for incremental repair session %s has failed because it
> encountered intersecting sstables belonging to another incremental repair
> session (%s). This is by starting an incremental repair session before a
> previous one has completed. Check nodetool repair_admin for hung sessions and
> fix them."
--
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-15027) Handle IR prepare phase failures less race prone by waiting for all results
Stefan Podkowinski created CASSANDRA-15027:
--
Summary: Handle IR prepare phase failures less race prone by
waiting for all results
Key: CASSANDRA-15027
URL: https://issues.apache.org/jira/browse/CASSANDRA-15027
Project: Cassandra
Issue Type: Bug
Components: Consistency/Repair, Local/Compaction
Reporter: Stefan Podkowinski
Assignee: Stefan Podkowinski
Fix For: 4.x
Handling incremental repairs as a coordinator begins by sending a
{{PrepareConsistentRequest}} message to all participants, which may also
include the coordinator itself. Participants will run anti-compactions upon
receiving such a message and report the result of the operation back to the
coordinator.
Once we receive a failure response from any of the participants, we fail-fast
in {{CoordinatorSession.handlePrepareResponse()}}, which will in turn completes
the {{prepareFuture}} that {{RepairRunnable}} is blocking on. Then the repair
command will terminate with an error status, as expected.
The issue is that in case the node will both be coordinator and participant, we
may end up with a local session and submitted anti-compactions, which will be
executed without any coordination with the coordinator session (on same node).
This may result in situations where running repair commands right after
another, may cause overlapping execution of anti-compactions that will cause
the following (misleading) message to show up in the logs and will cause the
repair to fail again:
"Prepare phase for incremental repair session %s has failed because it
encountered intersecting sstables belonging to another incremental repair
session (%s). This is by starting an incremental repair session before a
previous one has completed. Check nodetool repair_admin for hung sessions and
fix them."
--
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-9384) Update jBCrypt dependency to version 0.4
[ https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770826#comment-16770826 ] Stefan Podkowinski commented on CASSANDRA-9384: --- The most sensible approach would probably to a) add a log warn statement for all 2.x/3.x users with the property set to 31 and ask them to migrate to different value b) update lib in 4.0, add NEWS.txt notice and fail hard with config error for 31 rounds > Update jBCrypt dependency to version 0.4 > > > Key: CASSANDRA-9384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9384 > Project: Cassandra > Issue Type: Bug >Reporter: Sam Tunnicliffe >Assignee: Dinesh Joshi >Priority: Major > Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x > > > https://bugzilla.mindrot.org/show_bug.cgi?id=2097 > Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 > indicate that this is now fixed, so we should update. > Thanks to [~Bereng] for identifying the issue. -- 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-9384) Update jBCrypt dependency to version 0.4
[
https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769688#comment-16769688
]
Stefan Podkowinski commented on CASSANDRA-9384:
---
First of all, this only effects users who set the
{{cassandra.auth_bcrypt_gensalt_log2_rounds}} system property to 31 for insane
hashing computation times (default is 10). For those who did, updating to 0.4
would now cause each bcrypt hashing call to fail
([0c28b698|https://github.com/djmdjm/jBCrypt/commit/0c28b698e79b132391be8333107040d774c79995])
and forces them to change the value to something else. I'm pretty sure you'd
also have to re-create all users, to update the stored hashes again with <31
rounds to make bcrypt.hashpw() accept those.
> Update jBCrypt dependency to version 0.4
>
>
> Key: CASSANDRA-9384
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9384
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Dinesh Joshi
>Priority: Major
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.11.x
>
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2097
> Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4
> indicate that this is now fixed, so we should update.
> Thanks to [~Bereng] for identifying the issue.
--
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] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Issue Comment Deleted] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Comment: was deleted
(was: Hi
Please see the attached file...
zip pass 1234567
Best Regards.
AvionTEq - Edelyn
From: j...@apache.org
Sent: Sun, 10 Feb 2019 20:55:00 +
To: commits@cassandra.apache.org
Subject: [jira] [Comment Edited] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16764562#comment-16764562
]
Dinesh Joshi edited comment on CASSANDRA-15017 at 2/10/19 8:54 PM:
---
Could you please ask your question on the cassandra-users mailing list?
http://cassandra.apache.org/community/
was (Author: djoshi3):
Could you please ask your question on the cassandra-users mailing list?
--
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
)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
>
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Updated] (CASSANDRA-15017) Unable to connect to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15017:
---
Attachment: (was: AvionTEq.zip)
> Unable to connect to CQLSH
> --
>
> Key: CASSANDRA-15017
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15017
> Project: Cassandra
> Issue Type: Bug
>Reporter: Saisharan
>Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> when trying to connect cqlsh i am getting error *Connection error: ('Unable
> to connect to any servers',*
> *{'127.0.0.1': ProtocolError('Unexpected response during Connection setup:
> AttributeError("\'module\' object has no attribute \'decompress\'",)',)}*
> *)*
> Installed python-snappy using apt-get... no issues
> But when installed with pip; the errors are
> *Collecting python-snappy*
> *Using cached
> [https://files.pythonhosted.org/packages/89/fe/a81a219c183c7e578b6f82d9c2425df045548877be6559358e8560c1e9fd/python-snappy-0.5.3.tar.gz]*
> *Building wheels for collected packages: python-snappy*
> *Running setup.py bdist_wheel for python-snappy ... error*
> *Complete output from command /usr/bin/python u -c "import setuptools,
> tokenize;_file='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(file);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file_, 'exec'))" bdist_wheel -d
> /tmp/tmpyBEeJ6pip-wheel --python-tag cp27:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running bdist_wheel*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g
> -fdebug-prefix-map=/build/python2.7-VlbVAf/python2.7-2.7.15=.
> -fstack-protector-strong -Wformat -Werror=format-security -fPIC
> -I/usr/include/python2.7 -c snappy/snappymodule.cc -o
> build/temp.linux-x86_64-2.7/snappy/snappymodule.o*
> *cc1plus: warning: command line option '-Wstrict-prototypes' is valid for
> C/ObjC but not for C++*
> *snappy/snappymodule.cc:31:10: fatal error: snappy-c.h: No such file or
> directory*
> *#include *
> *^~~~*
> *compilation terminated.*
> *error: command 'x86_64-linux-gnu-gcc' failed with exit status 1*
> **
> *Failed building wheel for python-snappy*
> *Running setup.py clean for python-snappy*
> *Failed to build python-snappy*
> *Installing collected packages: python-snappy*
> *Running setup.py install for python-snappy ... error*
> *Complete output from command /usr/bin/python -u -c "import setuptools,
> tokenize;__file__='/tmp/pip-build-P7pulc/python-snappy/setup.py';f=getattr(tokenize,
> 'open', open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record
> /tmp/pip-4Ie8H2-record/install-record.txt --single-version-externally-managed
> --compile --user --prefix=:*
> */usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution
> option: 'cffi_modules'*
> *warnings.warn(msg)*
> *running install*
> *running build*
> *running build_py*
> *creating build*
> *creating build/lib.linux-x86_64-2.7*
> *creating build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__init__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/hadoop_snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi_builder.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_cffi.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/__main__.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy.py -> build/lib.linux-x86_64-2.7/snappy*
> *copying snappy/snappy_formats.py -> build/lib.linux-x86_64-2.7/snappy*
> *running build_ext*
> *building 'snappy._snappy' extension*
> *creating build/temp.linux-x86_64-2.7*
> *creating build/temp.linux-x86_64-2.7/snappy*
> *x86_64-linux-gnu-gcc -pthread -DNDEBUG
[jira] [Commented] (CASSANDRA-15012) token_generator_test.TestTokenGenerator test fails on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766141#comment-16766141
]
Stefan Podkowinski commented on CASSANDRA-15012:
There still seems to be an issue when running \{{./tools/bin/token-generator}
interactively w/o parameters with Python3:
{noformat}
Traceback (most recent call last):
File "./tools/bin/token-generator", line 354, in
res = main(opts, args)
File "./tools/bin/token-generator", line 335, in main
args = get_dc_sizes_interactive()
File "./tools/bin/token-generator", line 319, in get_dc_sizes_interactive
dcs = readnum(" How many datacenters will participate in this Cassandra
cluster?", min=1)
File "./tools/bin/token-generator", line 302, in readnum
x = raw_input(prompt + ' ')
NameError: name 'raw_input' is not defined{noformat}
> token_generator_test.TestTokenGenerator test fails on 2.2
> -
>
> Key: CASSANDRA-15012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15012
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Minor
> Labels: beginner, dtest, test
> Fix For: 2.2.x
>
>
> While running tests for the 2.2.14 candidate I noticed that the
> {{TestTokenGenerator}} dtests are broken. I reproduced locally as well, the
> issue appears to be that we're running a python2 script with python3 (since
> dtests run python3 now).
> Should be a quick fix to make the token generator script py2/3 compatible.
> Example local run:
> {noformat}
> pytest --cassandra-dir=/home/josephl/pg/cassandra_2 -k TestTokenGenerator
>
> 1 ↵
> ===
> test session starts
>
> platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
> rootdir: /home/josephl/pg/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.3.3, flaky-3.4.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 1028 items / 1025 deselected
>
>
>
> token_generator_test.py FFF
>
>
>[100%]
> =
> FAILURES
> =
> _
> TestTokenGenerator.test_multi_dc_tokens_default
> __
> self =
> def test_multi_dc_tokens_default(self):
> > self._multi_dc_tokens()
> token_generator_test.py:167:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> token_generator_test.py:153: in _multi_dc_tokens
> generated_tokens =
> self.call_token_generator(self.cluster.get_install_dir(), random, dc_nodes)
> token_generator_test.py:43: in call_token_generator
> token_gen_output = subprocess.check_output(args)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> input = None, timeout = None, check = True, popenargs =
> (['/home/josephl/pg/cassandra_2/tools/bin/token-generator', '3', '5'],),
> kwargs = {'stdout': -1}, process = 0x7f5188b80208>, stdout = b'', stderr = None
> retcode = 1
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default,
[jira] [Commented] (CASSANDRA-15012) token_generator_test.TestTokenGenerator test fails on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761569#comment-16761569
]
Stefan Podkowinski commented on CASSANDRA-15012:
I came in CASSANDRA-14561 to the conclusion to just let the test die with 2.x.
But will have a look, now since you fixed it.
> token_generator_test.TestTokenGenerator test fails on 2.2
> -
>
> Key: CASSANDRA-15012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15012
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Joseph Lynch
>Priority: Minor
> Labels: beginner, dtest, test
> Fix For: 2.2.x
>
>
> While running tests for the 2.2.14 candidate I noticed that the
> {{TestTokenGenerator}} dtests are broken. I reproduced locally as well, the
> issue appears to be that we're running a python2 script with python3 (since
> dtests run python3 now).
> Should be a quick fix to make the token generator script py2/3 compatible.
> Example local run:
> {noformat}
> pytest --cassandra-dir=/home/josephl/pg/cassandra_2 -k TestTokenGenerator
>
> 1 ↵
> ===
> test session starts
>
> platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
> rootdir: /home/josephl/pg/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.3.3, flaky-3.4.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 1028 items / 1025 deselected
>
>
>
> token_generator_test.py FFF
>
>
>[100%]
> =
> FAILURES
> =
> _
> TestTokenGenerator.test_multi_dc_tokens_default
> __
> self =
> def test_multi_dc_tokens_default(self):
> > self._multi_dc_tokens()
> token_generator_test.py:167:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> token_generator_test.py:153: in _multi_dc_tokens
> generated_tokens =
> self.call_token_generator(self.cluster.get_install_dir(), random, dc_nodes)
> token_generator_test.py:43: in call_token_generator
> token_gen_output = subprocess.check_output(args)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> input = None, timeout = None, check = True, popenargs =
> (['/home/josephl/pg/cassandra_2/tools/bin/token-generator', '3', '5'],),
> kwargs = {'stdout': -1}, process = 0x7f5188b80208>, stdout = b'', stderr = None
> retcode = 1
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default, stdout and stderr are not captured, and those
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
> them.
>
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the
> return code
> in the returncode attribute, and output & stderr attributes if those
> streams
> were captured.
>
> If timeout is given, and the process takes too long, a TimeoutExpired
> exception will
[jira] [Updated] (CASSANDRA-15012) token_generator_test.TestTokenGenerator test fails on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Podkowinski updated CASSANDRA-15012:
---
Reviewers: Stefan Podkowinski
Reviewer: Stefan Podkowinski
> token_generator_test.TestTokenGenerator test fails on 2.2
> -
>
> Key: CASSANDRA-15012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15012
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Joseph Lynch
>Priority: Minor
> Labels: beginner, dtest, test
> Fix For: 2.2.x
>
>
> While running tests for the 2.2.14 candidate I noticed that the
> {{TestTokenGenerator}} dtests are broken. I reproduced locally as well, the
> issue appears to be that we're running a python2 script with python3 (since
> dtests run python3 now).
> Should be a quick fix to make the token generator script py2/3 compatible.
> Example local run:
> {noformat}
> pytest --cassandra-dir=/home/josephl/pg/cassandra_2 -k TestTokenGenerator
>
> 1 ↵
> ===
> test session starts
>
> platform linux -- Python 3.6.7, pytest-3.6.4, py-1.7.0, pluggy-0.7.1
> rootdir: /home/josephl/pg/cassandra-dtest, inifile: pytest.ini
> plugins: timeout-1.3.3, flaky-3.4.0
> timeout: 900.0s
> timeout method: signal
> timeout func_only: False
> collected 1028 items / 1025 deselected
>
>
>
> token_generator_test.py FFF
>
>
>[100%]
> =
> FAILURES
> =
> _
> TestTokenGenerator.test_multi_dc_tokens_default
> __
> self =
> def test_multi_dc_tokens_default(self):
> > self._multi_dc_tokens()
> token_generator_test.py:167:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> token_generator_test.py:153: in _multi_dc_tokens
> generated_tokens =
> self.call_token_generator(self.cluster.get_install_dir(), random, dc_nodes)
> token_generator_test.py:43: in call_token_generator
> token_gen_output = subprocess.check_output(args)
> /usr/lib/python3.6/subprocess.py:336: in check_output
> **kwargs).stdout
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _
> input = None, timeout = None, check = True, popenargs =
> (['/home/josephl/pg/cassandra_2/tools/bin/token-generator', '3', '5'],),
> kwargs = {'stdout': -1}, process = 0x7f5188b80208>, stdout = b'', stderr = None
> retcode = 1
> def run(*popenargs, input=None, timeout=None, check=False, **kwargs):
> """Run command with arguments and return a CompletedProcess instance.
>
> The returned instance will have attributes args, returncode, stdout
> and
> stderr. By default, stdout and stderr are not captured, and those
> attributes
> will be None. Pass stdout=PIPE and/or stderr=PIPE in order to capture
> them.
>
> If check is True and the exit code was non-zero, it raises a
> CalledProcessError. The CalledProcessError object will have the
> return code
> in the returncode attribute, and output & stderr attributes if those
> streams
> were captured.
>
> If timeout is given, and the process takes too long, a TimeoutExpired
> exception will be raised.
>
> There is an optional argument "input", allowing you to
> pass
[jira] [Updated] (CASSANDRA-14993) Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService
[ https://issues.apache.org/jira/browse/CASSANDRA-14993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14993: --- Resolution: Fixed Fix Version/s: (was: 4.0.x) (was: 3.11.x) (was: 3.0.x) 4.0 3.11.5 3.0.19 Status: Resolved (was: Ready to Commit) Thanks, Ariel! Merged as c94a6aa7e5dd6d to cassandra-3.0 Tests CircleCI: [3.0|https://circleci.com/workflow-run/f8154177-162a-416e-ad79-4c3c86f66906] [3.11|https://circleci.com/workflow-run/eaaf37f8-ea9e-4a0a-b138-c26855e44309] [trunk|https://circleci.com/workflow-run/76cab84e-33f8-45b8-ba4a-2d5ba8fa37a3] > Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService > - > > Key: CASSANDRA-14993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14993 > Project: Cassandra > Issue Type: Bug >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Major > Fix For: 3.0.19, 3.11.5, 4.0 > > > Actively handling CorruptSSTableExceptions and FSErrors currently only > happens during opening of sstables and in the default exception handler. > What's missing is to catch these in AbstractLocalAwareExecutorService as > well. Therefor I propose to add calls to > FileUtils.handleCorruptSSTable/handleFSError there, too, so we don't miss > invoking the disk failure policy in that case. -- 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-14939) fix some operational holes in incremental repair
[
https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757075#comment-16757075
]
Stefan Podkowinski commented on CASSANDRA-14939:
Can you please also add {{parentRepairSession}} to
[this|https://github.com/apache/cassandra/blob/a05785d82c621c9cd04d8a064c38fd2012ef981c/src/java/org/apache/cassandra/repair/RepairSession.java#L268]
log statement, so we can get a link between parent and child sessionIds in the
log files?
> fix some operational holes in incremental repair
>
>
> Key: CASSANDRA-14939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14939
> Project: Cassandra
> Issue Type: Bug
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Major
> Fix For: 4.0
>
>
> Incremental repair has a few operational rough spots that make it more
> difficult to fully automate and operate at scale than it should be.
> * Visibility into whether pending repair data exists for a given token range.
> * Ability to force promotion/demotion of data for completed sessions instead
> of waiting for compaction.
> * Get the most recent repairedAt timestamp for a given token range.
--
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-14806) CircleCI workflow improvements and Java 11 support
[
https://issues.apache.org/jira/browse/CASSANDRA-14806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753986#comment-16753986
]
Stefan Podkowinski commented on CASSANDRA-14806:
I think ccm must be updated first for the new git url, so the tests actually
run. Can you try {{spod/cassandra-testing-ubuntu1810-java11-w-dependencies}} as
new docker image?
> CircleCI workflow improvements and Java 11 support
> --
>
> Key: CASSANDRA-14806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14806
> Project: Cassandra
> Issue Type: Improvement
> Components: Build, Legacy/Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>Priority: Major
>
> The current CircleCI config could use some cleanup and improvements. First of
> all, the config has been made more modular by using the new CircleCI 2.1
> executors and command elements. Based on CASSANDRA-14713, there's now also a
> Java 11 executor that will allow running tests under Java 11. The {{build}}
> step will be done using Java 11 in all cases, so we can catch any regressions
> for that and also test the Java 11 multi-jar artifact during dtests, that
> we'd also create during the release process.
> The job workflow has now also been changed to make use of the [manual job
> approval|https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval]
> feature, which now allows running dtest jobs only on request and not
> automatically with every commit. The Java8 unit tests still do, but that
> could also be easily changed if needed. See [example
> workflow|https://circleci.com/workflow-run/be25579d-3cbb-4258-9e19-b1f571873850]
> with start_ jobs being triggers needed manual approval for starting the
> actual jobs.
--
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-14999) Incorrect fallback calculation of getApproximateKeyCount
Stefan Podkowinski created CASSANDRA-14999: -- Summary: Incorrect fallback calculation of getApproximateKeyCount Key: CASSANDRA-14999 URL: https://issues.apache.org/jira/browse/CASSANDRA-14999 Project: Cassandra Issue Type: Bug Reporter: Stefan Podkowinski Creating a key count for a number of sstables depends on a probabilistic hyperloglog data structure for estimating cardinality of keys. In case of any errors, we'll fallback to [some code|https://github.com/apache/cassandra/blob/7d138e20ea987d44fffbc47de4674b253b7431ff/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L294] that does not calculate the cardinality, but simply creates a sum of all estimated keys for all sstables. This will lead to very different results for larger numbers of sstables with identical keys. We should have a look at the possible implications of that. Do we depend on this value for sizing bloom filters? -- 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-14993) Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService
[ https://issues.apache.org/jira/browse/CASSANDRA-14993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16751124#comment-16751124 ] Stefan Podkowinski commented on CASSANDRA-14993: inspectThrowable is called in any case, either in DefaultFSErrorHandler.handleCorruptSSTable/handleFSError(), or in the else statement. Should we inspect nested exceptions for FSError? Not 100% sure, but I'd probably first start fixing the logging statement, so we get proper stack traces and see what we get. > Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService > - > > Key: CASSANDRA-14993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14993 > Project: Cassandra > Issue Type: Bug >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Major > Fix For: 3.0.x, 3.11.x, 4.0.x > > > Actively handling CorruptSSTableExceptions and FSErrors currently only > happens during opening of sstables and in the default exception handler. > What's missing is to catch these in AbstractLocalAwareExecutorService as > well. Therefor I propose to add calls to > FileUtils.handleCorruptSSTable/handleFSError there, too, so we don't miss > invoking the disk failure policy in that case. -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16750382#comment-16750382 ] Stefan Podkowinski commented on CASSANDRA-14970: What you're referring to in the ticket description is the distribution policy, not the release policy. The later doesn't mention any requirement for PMCs to verify checksum, only the detached signature. So I don't see any need to generate any checksums at all, before voting and eventually copying new artifacts into the dist svn tree. I'd also argue that generating checksums locally in finish_release.sh will make things necessarily more complex, compared to generating them via ant and upload+download them from nexus again later and then copy to dist. > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Blocker > Fix For: 2.1.21, 2.2.14, 3.0.18, 3.11.4, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749096#comment-16749096 ] Stefan Podkowinski commented on CASSANDRA-14970: Also, I think the ultimate goal here should be to provide the sha256/512 files for everything released at [https://dist.apache.org/repos/dist/release/]. Can't we simply copy the checksum files there, as part of uploading other resources to the dist svn tree (finish_release.sh)? > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Blocker > Fix For: 2.1.21, 2.2.14, 3.0.18, 3.11.4, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-14970) New releases must supply SHA-256 and/or SHA-512 checksums
[ https://issues.apache.org/jira/browse/CASSANDRA-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749059#comment-16749059 ] Stefan Podkowinski commented on CASSANDRA-14970: Can you add the checksums as part of a comma separate list to an addition [files|http://maven.apache.org/plugins/maven-gpg-plugin/sign-and-deploy-file-mojo.html#files] attribute? What exactly did you try so far to make the sign-and-deploy-file step work? > New releases must supply SHA-256 and/or SHA-512 checksums > - > > Key: CASSANDRA-14970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14970 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Michael Shuler >Assignee: Michael Shuler >Priority: Blocker > Fix For: 2.1.21, 2.2.14, 3.0.18, 3.11.4, 4.0 > > Attachments: > 0001-Update-downloads-for-sha256-sha512-checksum-files.patch, > 0001-Update-release-checksum-algorithms-to-SHA-256-SHA-512.patch, > ant-publish-checksum-fail.jpg, build_cassandra-2.1.png, build_trunk.png > > > Release policy was updated around 9/2018 to state: > "For new releases, PMCs MUST supply SHA-256 and/or SHA-512; and SHOULD NOT > supply MD5 or SHA-1. Existing releases do not need to be changed." > build.xml needs to be updated from MD5 & SHA-1 to, at least, SHA-256 or both. > cassandra-builds/cassandra-release scripts need to be updated to work with > the new checksum files. > http://www.apache.org/dev/release-distribution#sigs-and-sums -- 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-14993) Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService
[ https://issues.apache.org/jira/browse/CASSANDRA-14993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14993: --- Status: Patch Available (was: In Progress) > Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService > - > > Key: CASSANDRA-14993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14993 > Project: Cassandra > Issue Type: Bug >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Major > Fix For: 3.0.x, 3.11.x, 4.0.x > > > Actively handling CorruptSSTableExceptions and FSErrors currently only > happens during opening of sstables and in the default exception handler. > What's missing is to catch these in AbstractLocalAwareExecutorService as > well. Therefor I propose to add calls to > FileUtils.handleCorruptSSTable/handleFSError there, too, so we don't miss > invoking the disk failure policy in that case. -- 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-14993) Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService
[ https://issues.apache.org/jira/browse/CASSANDRA-14993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14993: --- Fix Version/s: (was: 2.2.x) > Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService > - > > Key: CASSANDRA-14993 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14993 > Project: Cassandra > Issue Type: Bug >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Major > Fix For: 3.0.x, 3.11.x, 4.0.x > > > Actively handling CorruptSSTableExceptions and FSErrors currently only > happens during opening of sstables and in the default exception handler. > What's missing is to catch these in AbstractLocalAwareExecutorService as > well. Therefor I propose to add calls to > FileUtils.handleCorruptSSTable/handleFSError there, too, so we don't miss > invoking the disk failure policy in that case. -- 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-14993) Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService
Stefan Podkowinski created CASSANDRA-14993: -- Summary: Catch CorruptSSTableExceptions and FSErrors in ALAExecutorService Key: CASSANDRA-14993 URL: https://issues.apache.org/jira/browse/CASSANDRA-14993 Project: Cassandra Issue Type: Bug Reporter: Stefan Podkowinski Assignee: Stefan Podkowinski Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x Actively handling CorruptSSTableExceptions and FSErrors currently only happens during opening of sstables and in the default exception handler. What's missing is to catch these in AbstractLocalAwareExecutorService as well. Therefor I propose to add calls to FileUtils.handleCorruptSSTable/handleFSError there, too, so we don't miss invoking the disk failure policy in that case. -- 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-14985) CircleCI docker image should bake in more dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-14985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-14985: --- Status: Ready to Commit (was: Patch Available) > CircleCI docker image should bake in more dependencies > > > Key: CASSANDRA-14985 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14985 > Project: Cassandra > Issue Type: Test > Components: Test/dtest, Test/unit >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > It's pretty frequent especially in the upgrade tests for either maven or > github to fail. I think they are detecting the thundering herd of containers > all pulling stuff at the same time and opting out. > We can reduce this especially for maven dependencies since most are hardly > ever changing by downloading everything we can in advance and baking it into > the image. > When building the docker image Initialize the local maven repository by > running ant maven-ant-tasks-retrieve-build for 2.1-trunk and do the same with > CCM and the Apache repository. -- 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-14985) CircleCI docker image should bake in more dependencies
[ https://issues.apache.org/jira/browse/CASSANDRA-14985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746407#comment-16746407 ] Stefan Podkowinski commented on CASSANDRA-14985: Just to be clear, I'm not at all against updating the base image or caching dependencies. But I'd rather avoid the situation where someone only wants to update cached dependencies and accidentally updates other packages from the main image as well. CCM is a good example, as updating CCM was not a goal of this ticket and yet still happened, just by touching the base image. So lets just have two ways of either explicitly updating the base or caching image and just avoid these issues. Anyways, feel free to commit the added separate Dockerfile. > CircleCI docker image should bake in more dependencies > > > Key: CASSANDRA-14985 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14985 > Project: Cassandra > Issue Type: Test > Components: Test/dtest, Test/unit >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > Fix For: 4.0 > > > It's pretty frequent especially in the upgrade tests for either maven or > github to fail. I think they are detecting the thundering herd of containers > all pulling stuff at the same time and opting out. > We can reduce this especially for maven dependencies since most are hardly > ever changing by downloading everything we can in advance and baking it into > the image. > When building the docker image Initialize the local maven repository by > running ant maven-ant-tasks-retrieve-build for 2.1-trunk and do the same with > CCM and the Apache repository. -- 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-14985) CircleCI docker image should bake in more dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-14985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745246#comment-16745246
]
Stefan Podkowinski commented on CASSANDRA-14985:
The maven dependencies should be pulled only once by the single CI "build" step
and persisted to the workspace, before spawning the parallel containers. But it
just does this for the version that is to be tested. I also get why github
would block us for downloading 200x cassandra distributions in parallel.
Can you create a separate Dockerfile with your added steps that is based on the
one we used so far (referred to by {{From}})? I'd like to avoid unintentionally
upgrading packages in the base image, in case you just want to update maven/ccm
deps. Also collapsing run commands, using multi-line arguments, should prevent
creating a new layer for every line and make them more readable.
On the long run, we should probably give the CircleCI [caching
feature|https://circleci.com/docs/2.0/caching/] a try, after CASSANDRA-14806
was merged.
> CircleCI docker image should bake in more dependencies
>
>
> Key: CASSANDRA-14985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14985
> Project: Cassandra
> Issue Type: Test
> Components: Test/dtest, Test/unit
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Major
> Fix For: 4.0
>
>
> It's pretty frequent especially in the upgrade tests for either maven or
> github to fail. I think they are detecting the thundering herd of containers
> all pulling stuff at the same time and opting out.
> We can reduce this especially for maven dependencies since most are hardly
> ever changing by downloading everything we can in advance and baking it into
> the image.
> When building the docker image Initialize the local maven repository by
> running ant maven-ant-tasks-retrieve-build for 2.1-trunk and do the same with
> CCM and the Apache repository.
--
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-14975) cqlsh dtests are not running in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-14975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741878#comment-16741878 ] Stefan Podkowinski commented on CASSANDRA-14975: The title of CASSANDRA-14298 might be a bit misleading, but the latest attached patch does indeed address dtest's cqlsh_tests. Some of the tests have explicitly been disabled, until we've ported cqlshlib to Python 3, but most of the tests will pass now after applying the patch. > cqlsh dtests are not running in CircleCI > > > Key: CASSANDRA-14975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14975 > Project: Cassandra > Issue Type: Test > Components: Test/dtest >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > > Right now the dtests skip these tests because most don't pass. Originally > they weren't being collected because the test files end in_tests.py instead > of _test.py, but I fixed that by adding _tests.py to the list of recognized > patterns. > Get them all running in CircleCI. Nothing special they will be part of the > existing dtest jobs. -- 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-14975) cqlsh dtests are not running in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-14975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740632#comment-16740632 ] Stefan Podkowinski commented on CASSANDRA-14975: There's been progress on that already in CASSANDRA-14298 It's not as trivial. Also some tests won't run at all, before porting cqlsh/cqlshlib to Python3 IIRC. > cqlsh dtests are not running in CircleCI > > > Key: CASSANDRA-14975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14975 > Project: Cassandra > Issue Type: Test > Components: Test/dtest >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Major > > Right now the dtests skip these tests because most don't pass. Originally > they weren't being collected because the test files end in_tests.py instead > of _test.py, but I fixed that by adding _tests.py to the list of recognized > patterns. > Get them all running in CircleCI. Nothing special they will be part of the > existing dtest jobs. -- 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-14968) Investigate GPG signing of deb and rpm repositories via bintray
[
https://issues.apache.org/jira/browse/CASSANDRA-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16738481#comment-16738481
]
Stefan Podkowinski commented on CASSANDRA-14968:
So what we're currently doing is to add signatures at two places: as part of
the package metadata and for the repository metadata. Handling the first is
what confuses me the most at the moment. Take the RPMs for example:
{code}
rpm -K cassandra-3.11.3-1.noarch.rpm
cassandra-3.11.3-1.noarch.rpm: digests SIGNATURES NOT OK
rpm --import https://www.apache.org/dist/cassandra/KEYS
rpm -K cassandra-3.11.3-1.noarch.rpm
cassandra-3.11.3-1.noarch.rpm: digests signatures OK
{code}
As you can see, we can verify the signature that comes with the RPM by
importing the KEYS file.
But I couldn't get this to work for ignite at all. Even after importing both
their own KEYS and the Bintray/JFrog key.
{code}
rpm --import KEYS ignite-key.asc
rpm -K apache-ignite-2.7.0-1.noarch.rpm
apache-ignite-2.7.0-1.noarch.rpm: digests SIGNATURES NOT OK
{code}
Maybe I'm just missing something here and the package can be installed just
fine from the Bintray yum repo, even with gpgcheck=1. I wasn't able to test
this directly yet.
My question is, does Bintray do a debsign/rpmsign with their own key, after
uploading an artifact? Or does it just create the dettached .asc signatures for
packages and repo metadata?
> Investigate GPG signing of deb and rpm repositories via bintray
> ---
>
> Key: CASSANDRA-14968
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14968
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Shuler
>Priority: Major
> Labels: packaging
>
> Currently, the release manager uploads debian packages and built/signed
> metadata to a generic bintray repository. Perhaps we could utilize the GPG
> signing feature of the repository, post-upload, via the bintray GPG signing
> feature.
> https://www.jfrog.com/confluence/display/BT/Managing+Uploaded+Content#ManagingUploadedContent-GPGSigning
> Depends on CASSANDRA-14967
--
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
