Hi,
Since I have limited time working on the CEP-32, I'd appreciate the
collaboration to make this CEP the reality.
Another thing I'm thinking of is to reduce its scope to only the
OpenTelemetry configuration and the way to work only with OpenTelemetry
Tracing.
If it's possible to create sub CEP
CEP-1 is still completely relevant and we could send an update but as it
stands right now we’ve made a ton of progress and would like to focus on
getting to a release so it’s real for the community.
On Mon, Sep 30, 2024 at 5:31 PM Patrick McFadin wrote:
> There are two easy choices.
>
> 1 - Re-f
There are two easy choices.
1 - Re-furbish CEP-1 and start a [DISCUSS] thread
2 - Close out CEP-1 and Propose something fresh and start a [DISCUSS]
Thread on that.
Do you think there is enough in CEP-1 to keep moving with or is it
completely wrong?
Patrick
On Mon, Sep 30, 2024 at 4:53 PM Franci
Hi folks,
I feel I need to update the status of CEP-1 as it currently stands.
For context, the Cassandra Sidecar project has had a steady flow of
contributions in the past couple of years. And there is a steady stream
of upcoming contributions, i.e live migration (CEP-40), CDC (CEP-44),
and many o
> This is the type of hidden subproject that will get us into trouble with the
> board/foundation. I'm sure it's getting enough committer eyeballs, and some
> PMC oversight, but maybe not enough.
I don't agree with the qualifier of it as being hidden. It's definitely lower
traffic than the mai
LGTM
On Mon, Sep 30, 2024, at 2:17 PM, Štefan Miklošovič wrote:
> Okay, that works, so summary:
>
> 1) CEP-12 will be delivered WITHOUT interacting with Chronicle Queues,
> something else will be used (most probably just a simple logger logging to a
> text file, that is just enough for somethin
I hear LLMs are good for this. Just something I saw on YouTube :D
On Mon, Sep 30, 2024 at 5:40 AM Štefan Miklošovič
wrote:
> I think there was some discussion about putting that all to the website
> which never materialized.
>
> On Mon, Sep 30, 2024 at 2:37 PM Josh McKenzie
> wrote:
>
>> Today
The Cassandra team is pleased to announce the release of Apache Cassandra
version 5.0.1.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
http://cassandra.apache.org/
Downloads of source an
I'm mentioning it because I was surprised and I feel like I generally have
a finger on the pulse of the project.
I would love to talk about it more and get more community support and
interest.
On Mon, Sep 30, 2024 at 11:01 AM Mick Semb Wever wrote:
> Agree with Jon, Josh and Patrick here.
>
> T
Okay, that works, so summary:
1) CEP-12 will be delivered WITHOUT interacting with Chronicle Queues,
something else will be used (most probably just a simple logger logging to
a text file, that is just enough for something like diagnostic logs which
are logged very sparsely)
2) We will NOT use Ch
Agree with Jon, Josh and Patrick here.
This is the type of hidden subproject that will get us into trouble with
the board/foundation. I'm sure it's getting enough committer eyeballs,
and some PMC oversight, but maybe not enough. Addressing the more material
points that Jon mentions is the best
I think it depends on what lens you're looking at the sidecar through.
If you're actively working on it, and pulling it into your own infra,
sure. It's a thing.
If you're an outsider? I have a hard time seeing it.
- No documentation as to what it does
- No releases
- No build instructions
- Tr
Thanks for the discussions. I do anticipate that Accord will make things
very much better, however I think if consumers are ultimately going to be
replay the log into some other system (say Apache Iceberg) exact-once
delivery will always be tricky, but perhaps not entirely necessary given
the linea
Vote passes with six +1 votes (3 binding).
Thanks all!
- Bret -
On Mon, Sep 30, 2024 at 10:19 AM João Reis wrote:
> +1 (nb)
>
> Bret McGuire escreveu (quinta, 26/09/2024 à(s)
> 21:46):
>
>>Greetings all!
>>
>>I’m proposing the Cassandra Gocql Driver 1.7.0 for release.
>>
>
+1 (nb)
Bret McGuire escreveu (quinta, 26/09/2024 à(s)
21:46):
>Greetings all!
>
>I’m proposing the Cassandra Gocql Driver 1.7.0 for release.
>
> sha1: 953e0df999cabb3f5eef714df9921c00e9f632c2
> git: https://github.com/apache/cassandra-gocql-driver/tree/v1.7.0-rc1
>
>The Source relea
The CEP for the sidecar has stalled. The sidecar itself is very much alive and
a thing.
CEP != artifact.
We should definitely clean that up though.
On Mon, Sep 30, 2024, at 10:59 AM, Dinesh Joshi wrote:
> Patrick, could you please elaborate? The Sidecar has been a thing for a while
> now.
>
>
I say we do CEP-12 w/out using chronicle and have a follow up JIRA to replace
chronicle w/something else.
Seems like there's a reasonable consensus around at least that subset of things
given the discussion here. As to what form that something else takes, well,
that's a topic for another day. :
Patrick, could you please elaborate? The Sidecar has been a thing for a
while now.
On Mon, Sep 30, 2024 at 7:51 AM Patrick McFadin wrote:
> I made the mistake of asking two things in one email.
>
> First thing I asked. Sidecar? Stalled CEP so why is this being talked
> about like this is a thing
I made the mistake of asking two things in one email.
First thing I asked. Sidecar? Stalled CEP so why is this being talked about
like this is a thing?
On Mon, Sep 30, 2024 at 7:21 AM Benedict wrote:
> Sorry Bernardo, you may have misunderstood me. I don’t have any concerns,
> I was suggesting
Sorry Bernardo, you may have misunderstood me. I don’t have any concerns, I was suggesting a possible future scenario where CDC for Kafka via sidecar is changed to use a hypothetical future topic subscription service provided by C*. It was meant to show that this CEP may be easily decoupled from an
+1
On Thu, Sep 26, 2024 at 10:49 PM Bret McGuire
wrote:
>Greetings all!
>
>I’m proposing the Cassandra Gocql Driver 1.7.0 for release.
>
> sha1: 953e0df999cabb3f5eef714df9921c00e9f632c2
> git: https://github.com/apache/cassandra-gocql-driver/tree/v1.7.0-rc1
>
>The Source release is a
"how complex should it be to rip out the chronicle format, insert some
other well defined and well known, and handle log rolling ourselves".
I think that it will be actually easier to do after CEP-12 is in because as
I mentioned it does housekeeping of what is there rigth now and refactors
it a l
My vote doesn't count, but this would be a +1 from me.
From: Brandon Williams
Sent: 30 September 2024 14:06
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra Gocql Driver 1.7.0
EXTERNAL EMAIL - USE CAUTION when clicking links or attachment
Thanks everyone for the comments.
Patrick:
The proposal includes a “best effort” approach for deduplication (some details
can be found on the Digest class comments on the PR here
https://github.com/apache/cassandra-analytics/pull/87/files#diff-3a09caecc1da13419d92cde56a7cfc7d253faac08182e6c2768b
I hear you. Not trying to shoehorn a change in w/CEP-12, just thinking through
"how complex should it be to rip out the chronicle format, insert some other
well defined and well known, and handle log rolling ourselves". My preference
(which I didn't indicate earlier) would be to have that done i
I don't understand why CEP-12 should be a vehicle for introducing changes
like that. That is something totally unrelated. I am not going to be the
one to implement anything beyond CEP-12 and I am not the one who is going
to replace it either so if we make it a hard requirement for CEP-12 then
CEP-1
On Mon, Sep 30, 2024 at 7:55 AM Josh McKenzie wrote:
>
> I'd strongly support either rolling the format change into the CEP-12
> proposal or having another CEP for introducing protobuf, spark, etc - some
> kind of more broadly adopted format, and removing chronicle from our stack.
+1, I too wou
+1
Kind Regards,
Brandon
On Thu, Sep 26, 2024 at 3:46 PM Bret McGuire wrote:
>
>Greetings all!
>
>I’m proposing the Cassandra Gocql Driver 1.7.0 for release.
>
> sha1: 953e0df999cabb3f5eef714df9921c00e9f632c2
> git: https://github.com/apache/cassandra-gocql-driver/tree/v1.7.0-rc1
>
>
+1. SHAs and contents lgtm.
On Mon, Sep 30, 2024, at 5:57 AM, Dmytro Tsapko wrote:
> Hello, LGTM.
>
> On Thu, Sep 26, 2024 at 11:46 PM Bret McGuire wrote:
>>Greetings all!
>>
>>I’m proposing the Cassandra Gocql Driver 1.7.0 for release.
>>
>> sha1: 953e0df999cabb3f5eef714df9921c00e9f63
> thinking more about stuff like protobuf and while I do see benefits of that,
> honestly, it just does not matter too much if it is done like that or not.
I disagree; I think having a language and environment agnostic file format
matters a great deal. Unless we're talking specifically about the
> I don't see much on how this would be handled other than "left to the end
> user to figure out."
My immediate thought when I read that was "Yes. But it's moving where we draw
the line of 'left to the end user to figure out' *much further* than it was
before".
This should only be necessary in
I think there was some discussion about putting that all to the website
which never materialized.
On Mon, Sep 30, 2024 at 2:37 PM Josh McKenzie wrote:
> Today I learned… I had no clue we had markdown files in src/java…
>
> Discoverability issues in our codebase?
>
> Well I never.
>
> ;)
>
> On S
> Today I learned… I had no clue we had markdown files in src/java…
Discoverability issues in our codebase?
Well I never.
;)
On Sat, Sep 28, 2024, at 10:39 PM, David Capwell wrote:
> Today I learned… I had no clue we had markdown files in src/java…
>
> $ find src/ -name '*.md'
> src//java/org/a
.
Proposing the test build of Cassandra 5.0.1 for release.
>
> sha1: c206e4509003ac4cd99147d821bd4b5d23bdf5e8
> Git: https://github.com/apache/cassandra/tree/5.0.1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1348/org/apache/cassandra/cassand
Hello, LGTM.
On Thu, Sep 26, 2024 at 11:46 PM Bret McGuire
wrote:
>Greetings all!
>
>I’m proposing the Cassandra Gocql Driver 1.7.0 for release.
>
> sha1: 953e0df999cabb3f5eef714df9921c00e9f632c2
> git: https://github.com/apache/cassandra-gocql-driver/tree/v1.7.0-rc1
>
>The Source re
That is all OK to mention. So as I read it correctly, Jon, myself, Andrew,
David - we all would like to see some cross-language events ingestion.
Other people do not seem to consider it important enough (just correct me
if I am wrong). I do not mind, I am 50:50, not an absolute must but sure,
let's
Yes, with accord it should be fairly easy to have reliable no-dupe log streaming without an elected leader. Given the broad set of use cases, I can imagine supporting some more native topic subscription API in C* rather than requiring Kafka, so perhaps any integration of Kafka with the sidecar can
37 matches
Mail list logo
