Re: Welcome Patrick McFadin as Cassandra Committer

[Aaron Ploetz]

Patrick FTW!!!

On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch  wrote:

> W! Congratulations Patrick!!
>
> -Joey
>
> On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:
>
>> The PMC members are pleased to announce that Patrick McFadin has accepted
>> the invitation to become committer today.
>>
>> Thanks a lot, Patrick, for everything you have done for this project and
>> its community through the years.
>>
>> Congratulations and welcome!
>>
>> The Apache Cassandra PMC members
>>
>

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode:
https://drive.google.com/file/d/1nvHs7o4JJC2P18mtR5MrbnNoeW5f44j1/view?usp=sharing

s2Ep1 - Patrick McFadin

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Saturday, March 4th (19:00 UTC).

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I have recording sessions scheduled with:
- Aaron Morton
- Loren Sands-Ramshaw (Temporal)

And I'm currently trying to nail down a time with Valeri:
- Valeri Karpov (MeanIT Software)

Thanks, everyone!

Aaron Ploetz

Re: Degradation of availability when using NTS and RF > number of racks

[Aaron Ploetz]

> I think it would be a worse experience to not warn and let the user
discover later when they can't write at QUORUM.

Agree.

Should we add a note in the cassandra.yaml comments as well?  Maybe in the
spot where default_keyspace_rf is defined?  On the other hand, that section
is pretty "wordy" already.  But calling it out in the yaml might not be a
bad idea.

Thanks,

Aaron


On Tue, Mar 7, 2023 at 11:12 AM Derek Chen-Becker 
wrote:

> I think that the warning would only be thrown in the case where a
> potentially QUORUM-busting configuration is used. I think it would be a
> worse experience to not warn and let the user discover later when they
> can't write at QUORUM.
>
> Cheers,
>
> Derek
>
> On Tue, Mar 7, 2023 at 9:32 AM Jeremiah D Jordan <
> jeremiah.jor...@gmail.com> wrote:
>
>> I agree with Paulo, it would be nice if we could figure out some way to
>> make new NTS work correctly, with a parameter to fall back to the “bad”
>> behavior, so that people restoring backups to a new cluster can get the
>> right behavior to match their backups.
>> The problem with only fixing this in a new strategy is we have a ton of
>> tutorials and docs out there which tell people to use NTS, so it would be
>> great if we could keep “use NTS” as the recommendation.  Throwing a warning
>> when someone uses NTS is kind of user hostile.  If someone just read some
>> tutorial or doc which told them “make your key space this way” and then
>> when they do that the database yells at them telling them they did it
>> wrong, it is not a great experience.
>>
>> -Jeremiah
>>
>> > On Mar 7, 2023, at 10:16 AM, Benedict  wrote:
>> >
>> > My view is that if this is a pretty serious bug. I wonder if
>> transactional metadata will make it possible to safely fix this for users
>> without rebuilding (only via opt-in, of course).
>> >
>> >> On 7 Mar 2023, at 15:54, Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com> wrote:
>> >>
>> >> Thanks everybody for the feedback.
>> >>
>> >> I think that emitting a warning upon keyspace creation (and
>> alteration) should be enough for starters. If somebody can not live without
>> 100% bullet proof solution over time we might choose some approach from the
>> offered ones. As the saying goes there is no silver bullet. If we decide to
>> implement that new strategy, we would probably emit warnings anyway on NTS
>> but it would be already done so just new strategy would be provided.
>> >>
>> >> 
>> >> From: Paulo Motta 
>> >> Sent: Monday, March 6, 2023 17:48
>> >> To: dev@cassandra.apache.org
>> >> Subject: Re: Degradation of availability when using NTS and RF >
>> number of racks
>> >>
>> >> NetApp Security WARNING: This is an external email. Do not click links
>> or open attachments unless you recognize the sender and know the content is
>> safe.
>> >>
>> >>
>> >>
>> >> It's a bit unfortunate that NTS does not maintain the ability to lose
>> a rack without loss of quorum for RF > #racks > 2, since this can be easily
>> achieved by evenly placing replicas across all racks.
>> >>
>> >> Since RackAwareTopologyStrategy is a superset of
>> NetworkTopologyStrategy, can't we just use the new correct placement logic
>> for newly created keyspaces instead of having a new strategy?
>> >>
>> >> The placement logic would be backwards-compatible for RF <= #racks. On
>> upgrade, we could mark existing keyspaces with RF > #racks with
>> use_legacy_replica_placement=true to maintain backwards compatibility and
>> log a warning that the rack loss guarantee is not maintained for keyspaces
>> created before the fix. Old keyspaces with RF <=#racks would still work
>> with the new replica placement. The downside is that we would need to keep
>> the old NTS logic around, or we could eventually deprecate it and require
>> users to migrate keyspaces using the legacy placement strategy.
>> >>
>> >> Alternatively we could have RackAwareTopologyStrategy and fail NTS
>> keyspace creation for RF > #racks and indicate users to use
>> RackAwareTopologyStrategy to maintain the quorum guarantee on rack loss or
>> set an override flag "support_quorum_on_rack_loss=false". This feels a bit
>> iffy though since it could potentially confuse users about when to use each
>> strategy.
>> >>
>> >> On Mon, Mar 6, 2023 at 5:51 AM Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com> wrote:
>> >> Hi all,
>> >>
>> >> some time ago we identified an issue with NetworkTopologyStrategy. The
>> problem is that when RF > number of racks, it may happen that NTS places
>> replicas in such a way that when whole rack is lost, we lose QUORUM and
>> data are not available anymore if QUORUM CL is used.
>> >>
>> >> To illustrate this problem, lets have this setup:
>> >>
>> >> 9 nodes in 1 DC, 3 racks, 3 nodes per rack. RF = 5. Then, NTS could
>> place replicas like this: 3 replicas in rack1, 1 replica in rack2, 1
>> replica in rack3. Hence, when rack1 is lost, we do not have QUORUM

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode:
https://drive.google.com/file/d/1_EOBpG3yiuptDJ-PU-3a7amSVvi7pgM8/view?usp=sharing

s2Ep2 - Aaron Morton

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Saturday, March 11th (22:00 UTC).

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

I have also recorded a session with Loren Sands-Ramshaw (Temporal), and
expect to submit that for approval tomorrow.  It will be the last one to
come out before Cassandra Forward.

For my guest pipeline, I have recording sessions scheduled with:
- Valeri Karpov (MeanIT Software)

Thanks, everyone!

Aaron Ploetz

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode:
https://drive.google.com/file/d/1IePasf681bU-7xRNl4tBzWvVG28y4tQK/view?usp=share_link

s2Ep3 - Loren Sands-Ramshaw
(You may have to download it to play)

FYI - Experimenting with a video podcast on this one.

It will remain in staging for 72 hours, going live (assuming no objections)
by Sunday, March 12th (17:00 UTC).

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I have recording sessions scheduled with:
- Valeri Karpov (MeanIT Software)

Looking for additional guests, so if you know someone who has a great use
case, let me know!

Thanks, everyone!

Aaron Ploetz

Re: Welcome our next PMC Chair Josh McKenzie

[Aaron Ploetz]

Congratulations, Josh!

And of course, thank you Mick for all you've done for the project while in
the PMC Chair role!

On Thu, Mar 23, 2023 at 7:44 AM Derek Chen-Becker 
wrote:

> Congratulations, Josh!
>
> On Thu, Mar 23, 2023, 4:23 AM Mick Semb Wever  wrote:
>
>> It is time to pass the baton on, and on behalf of the Apache Cassandra
>> Project Management Committee (PMC) I would like to welcome and congratulate
>> our next PMC Chair Josh McKenzie (jmckenzie).
>>
>> Most of you already know Josh, especially through his regular and
>> valuable project oversight and status emails, always presenting a balance
>> and understanding to the various views and concerns incoming.
>>
>> Repeating Paulo's words from last year: The chair is an administrative
>> position that interfaces with the Apache Software Foundation Board, by
>> submitting regular reports about project status and health. Read more about
>> the PMC chair role on Apache projects:
>> - https://www.apache.org/foundation/how-it-works.html#pmc
>> - https://www.apache.org/foundation/how-it-works.html#pmc-chair
>> - https://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers
>>
>> The PMC as a whole is the entity that oversees and leads the project and
>> any PMC member can be approached as a representative of the committee. A
>> list of Apache Cassandra PMC members can be found on:
>> https://cassandra.apache.org/_/community.html
>>
>

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode:
https://drive.google.com/file/d/1YoHbFwADEESdBgzhFgm43XVYTGatTBsU/view?usp=sharing

s2e4 - Val Karpov (Mongoose)
(You may have to download it to play)

It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, April 3rd.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I'm trying to coordinate with Rahul Singh.  But I am
looking for additional guests.  So if you know someone who has a great use
case, let me know!

Thanks, everyone!

Aaron Ploetz

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode:
https://drive.google.com/file/d/1E9HTuwkRf9W6W-9tM6PB0da8SRAd3g5j/view?usp=sharing

s2e5 - Rahul Singh (Anant)
(You may have to download it to play)

It will remain in staging for 72 hours, going live (assuming no objections)
by Sunday, April 16th.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I'm trying to coordinate with Rahul Singh.  But I am
looking for additional guests.  So if you know someone who has a great use
case, let me know!

Thanks, everyone!

Aaron Ploetz

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode:
https://drive.google.com/file/d/1E9HTuwkRf9W6W-9tM6PB0da8SRAd3g5j/view?usp=sharing

s2e5 - Rahul Singh (Anant)
(You may have to download it to play)

It will remain in staging for 72 hours, going live (assuming no objections)
by Sunday, April 16th.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I'm trying to coordinate with Charna Parkey and Mary
Grygleski.  But I am looking for additional guests.  So if you know someone
who has a great use case, let me know!

Thanks, everyone!

Aaron Ploetz

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode:
https://drive.google.com/file/d/1Rzmvj3db_chj6ZLvQ5G2bBLxIF_QaPCV/view?usp=sharing

s2e6 - Mary Grygleski (DataStax)
(You may have to download it to play)

It will remain in staging for 72 hours, going live (assuming no objections)
by Saturday, June 17th.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I'm working on coordinating with Charna Parkey and
Josh McKenzie.  But I am looking for additional guests.  So if you know
someone who has a great use case, let me know!

Thanks, everyone!

Aaron Ploetz

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode (audio only):
https://drive.google.com/file/d/1HmhtR1stWmtD8gJTFh3gKIye7lQKXN1y/view?usp=sharing

s2e7 - German Eighberger and Theo van Kraay (Microsoft)
(You may have to download it to play)

It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, July 10th.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I'm still coordinating with Josh McKenzie.  But I am
looking for additional guests.  So if you know someone who would be a
great guest, let me know!

Thanks, everyone!

Aaron

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode (video):
https://drive.google.com/file/d/1nu_h8JczmAI59GhnDunTI9Oew-TxmzNU/view?usp=sharing

s2e8 - Otavio Santana
(You may have to download it to play)

It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, August 28th.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

I am looking for additional guests.  So if you know someone who would be a
great guest, please let me know!

Thanks, everyone!

Aaron

New episode of The Apache Cassandra(R) Corner podcast!

[Aaron Ploetz]

Link to the next episode (video):
https://drive.google.com/file/d/1tm96RLPUesm3dXZYSVzzrIGKlSQsfag8/view?usp=sharing

s2e9 - Aaron Morton
(You may have to download it to play)

It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, September 11th.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

I am looking for additional guests.  So if you know someone who would be a
great guest, please let me know!

Thanks, everyone!

Aaron

New episode of the Apache Cassandra(R) Corner podcast

[Aaron Ploetz]

s2e10 - Dr. Charna Parkey
(You may have to download it to play)

https://drive.google.com/file/d/1L8gw--kRLDEit1Vmk51u32LQVIKOT6yr/view?usp=drive_link

It will remain in staging for 72 hours, going live (assuming no objections)
by Thursday, September 21st.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

I am looking for additional guests.  So if you know someone who would be a
great guest, please let me know!

Thanks, everyone!

Aaron

New episode of the Apache Cassandra(R) Corner podcast

[Aaron Ploetz]

s2e11 - Sarma Pydipally
(You may have to download it to play)

https://drive.google.com/file/d/1X98HjR0G3wnRaUUuUUvsDyvx05QZYXXN/view?usp=drive_link

It will remain in staging for 72 hours, going live (assuming no objections)
by Thursday, October 19th.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

I am looking for additional guests.  So if you know someone who would be a
great guest, please let me know!

Thanks, everyone!

Aaron

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Aaron Ploetz]

>
> If I had to pick a month of the year to release software used by large
> enterprises, it probably would be something like March instead of December.
> I have no good research to back that up, of course...
>

Can confirm. Many large enterprises (especially retailers) have been in
"holiday code freeze" for a few weeks already. Infrastructure teams will be
freezing all changes shortly (they get a few "buffer" weeks to scale-out
for holiday traffic). Everything is basically locked-down until the week
after New Years.

Once infra teams can push changes again, they'll likely have a backlog of
findings from their security team, indicating a list of things that need to
be patched/updated across all of their server instances. At Target, we
usually had to spend all of January playing "catch-up" to make the security
scans happy again.

Maybe by mid-February, they'll be ready to entertain doing a database
update. So the February/March timeframe is a good choice.

Aaron


On Mon, Oct 23, 2023 at 1:12 PM Josh McKenzie  wrote:

> If I had to pick a month of the year to release software used by large
> enterprises, it probably would be something like March instead of December.
>
> That's... a good point. If we end up on a cadence of major's in December
> (since we slipped to then for 4.1 and inherit that from that calendar year
> "pressure") we're setting ourselves up to release right in the largest
> consistent change-freeze window I know of for most users.
>
> It will be another 2.2 release.
>
> Let me live on with the stories I tell myself about the hordes of Windows
> users that appreciated Windows support before the Storage Engine rewrite,
> thank you very much. :D
>
> On Mon, Oct 23, 2023, at 1:57 PM, Caleb Rackliffe wrote:
>
> ...or like the end of January. Either way, feel free to ignore the "aside"
> :)
>
> On Mon, Oct 23, 2023 at 12:53 PM Caleb Rackliffe 
> wrote:
>
> Kind of in the same place as Benedict/Aleksey.
>
> If we release a 5.1 in, let's say...March of next year, the number of 5.0
> users is going to be very minimal. Nobody is going to upgrade anything
> important from now through the first half of January anyway, right? They're
> going to be making sure their existing clusters aren't exploding.
>
> (We still want TCM/Accord to be available to people to test by Summit, but
> that feels unrelated to whether we cut a 5.1 branch...)
>
> Aside: If I had to pick a month of the year to release software used by
> large enterprises, it probably would be something like March instead of
> December. I have no good research to back that up, of course...
>
> On Mon, Oct 23, 2023 at 12:19 PM Benedict  wrote:
>
>
> To be clear, I’m not making an argument either way about the path forwards
> we should take, just concurring about a likely downside of this proposal. I
> don’t have a strong opinion about how we should proceed.
>
>
> On 23 Oct 2023, at 18:16, Benedict  wrote:
>
> 
>
> I agree. If we go this route we should essentially announce an immediate
> 5.1 alpha at the same time as 5.0 GA, and I can’t see almost anybody
> rolling out 5.0 with 5.1 so close on its heels.
>
>
> On 23 Oct 2023, at 18:11, Aleksey Yeshchenko  wrote:
>
> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path
> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in
> one hop.
>
> Nobody likes going through these upgrades. So I personally expect 5.0 to
> be a largely ghost release if we go this route, adopted by few, just a
> permanent burden on the merge path to trunk.
>
> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord -
> there most certainly is - but with the expectation that 5.1 will follow up
> reasonably shortly after with all that *and* two highly anticipated
> features on top, I just don’t see the point. It will be another 2.2 release.
>
>
> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
>
> We discussed that at length in various other mailing threads Jeff - kind
> of settled on "we're committing to cutting a major (semver MAJOR or MINOR)
> every 12 months but want to remain flexible for exceptions when
> appropriate".
>
> And then we discussed our timeline for 5.0 this year and settled on the
> "let's try and get it out this calendar year so it's 12 months after 4.1,
> but we'll grandfather in TCM and Accord past freeze date if they can make
> it by October".
>
> So that's the history for how we landed here.
>
> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
> 5.1.0 is?
>
> This is my understanding, yes. Deprecation and support drop is predicated
> on the 5.0 release, not any specific features or anything.
>
> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>
>
>
> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
>
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
>
> I think this presumes that 5.0 GA

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Aaron Ploetz]

Even though my opinion doesn't really count here, I do feel compelled to
mention that:

 - No one expects a "beta" release to be perfect, but it does signal that
it is "close" to being ready.
 - An "alpha" release is in fact a LOT scarier than a "beta" release.

>From a user perspective, if I was coaching dev teams on selecting a build
based on newly available features, I would help them build up a dev/stage
cluster based on a beta (and make the "beta" part very clear to them).
However an alpha version just doesn't convey the same level of confidence.
When I test out an "alpha" of anything, I fully expect some things to just
be broken.

As for cutting a beta for the Summit; it makes sense that we'd want to get
some things fixed up before that. But it would also be great to be at the
point where we have a beta ready for folks to take a look at. We absolutely
could tell everyone to download the alpha and give it a spin. But more
people will be likely to do that for a beta than for an alpha.

Take that however you will.

Thanks,

Aaron


On Wed, Nov 29, 2023 at 9:54 AM Aleksey Yeshchenko 
wrote:

> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now,
> but I’m not sure there is significant value to be had from it. Merge the
> fixes for outstanding issues listed above, then cut beta1.
>
> With TCM and Accord pushed into 5.1, SAI is the headliner user-visible
> feature. It is what we want users to test. If we are to drive more people
> to test SAI, we should resolve the issues that we ourselves know of first.
> Respect our users’ time and effort - don’t make them bump into known bugs.
>
> P.S. I don’t believe that ‘alpha' vs. ‘beta' really makes a significant
> difference to people’s willingness to try out the build. For most folks
> both feel too raw to play with, and most of the rest would be equally
> adventurous enough for an alpha *or* a beta. This is just my gut feeling
> vs. your gut feeling, in absence of hard data.
>
> On 28 Nov 2023, at 21:17, Mick Semb Wever  wrote:
>
>
>
> So then cutting an alpha2 is possible.
>>
>
>
> Possible, but still leaves alpha1 as our mitigation plan and alpha2 as our
> best plan.  Doesn't seem worth it IMHO.
>
>
>

New episode of the Apache Cassandra(R) Corner podcast

[Aaron Ploetz]

s2e13 - Jonathan Ellis
(You may have to download it to play)

https://drive.google.com/file/d/1XNfVyIrTM1AIdqzrSDeww7Xe05f8pIdD/view?usp=sharing

It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, December 4th.

If anyone should have any questions or comments, please reach out to me.

Barring any additional sessions recorded live at the Cassandra Summit, this
is likely to be the last episode of 2023.

Thanks, everyone!

Aaron

Re: Voice of Apache (Feathercast) at summit?

[Aaron Ploetz]

Rich,

I'm happy to sit down for a session with you, as well!

Thanks,

Aaron


On Fri, Dec 8, 2023 at 8:05 AM Rahul Xavier Singh <
rahul.xavier.si...@gmail.com> wrote:

> I’m sure you have other people interested but would love to speak about
> the community aspect, how we’ve seen customers use it and how it continues
> to grow into what we need as technologists to help people build scalable
> platforms.
>
>
>
> On Tue, Dec 5, 2023 at 8:35 AM Rich Bowen  wrote:
>
>> Hey, folks. I'll be at Cassandra Summit next week, and was wondering if
>> any of you who might be there would be interested in doing a podcast
>> interview with me for Voice Of Apache (the podcast formerly known as
>> Feathercast - see https://feathercast.apache.org for context). Topics
>> might include something about 5.0, retrospectives on the last 13 years, or
>> whatever you think might be of interest.
>>
>> Let me know soon of anyone's interested/available, so I know to pack my
>> gear.
>>
>> Thanks!
>>
>> --Rich
>>
>

New episode of the Apache Cassandra(R) Corner!

[Aaron Ploetz]

s3e1 - Jon Haddad
(You may have to download it to play)

https://drive.google.com/file/d/1zZn8DSLvHiym3gx3V4IMlG8bkwnifP2F/view?usp=sharing

It will remain in staging for 72 hours, going live (assuming no objections)
by Thursday, February 29th.

If anyone should have any questions or comments, or if you or someone you
know wants to be a guest, please let me know!

Thanks, everyone!

Aaron

New episode of the Apache Cassandra(R) Corner!

[Aaron Ploetz]

s3e2 - Otavio Santana
(You may have to download it to play)

https://drive.google.com/file/d/1RZLP-mpq01LtYBbQPiYS0YbP4WKf0nKG/view?usp=drive_link

It will remain in staging for 72 hours, going live (assuming no objections)
by Thursday, April 11th.

If anyone should have any questions or comments, or if you or someone you
know wants to be a guest, please let me know!

Thanks, everyone!

Aaron

Re: Cassandra PMC Chair Rotation, 2024 Edition

[Aaron Ploetz]

Congratulations, Dinesh!

On Thu, Jun 20, 2024 at 10:51 AM Josh McKenzie  wrote:

> Another PMC Chair baton pass incoming! On behalf of the Apache Cassandra
> Project Management Committee (PMC) I would like to welcome and congratulate
> our next PMC Chair Dinesh Joshi (djoshi).
>
> Dinesh has been a member of the PMC for a few years now and many of you
> likely know him from his thoughtful, measured presence on many of our
> collective discussions as we've grown and evolved over the past few years.
>
> I appreciate the project trusting me as liaison with the board over the
> past year and look forward to supporting Dinesh in the role in the future.
>
> Repeating Mick (repeating Paulo's) words from last year: The chair is an
> administrative position that interfaces with the Apache Software Foundation
> Board, by submitting regular reports about project status and health. Read
> more about the PMC chair role on Apache projects:
> - https://www.apache.org/foundation/how-it-works.html#pmc
> - https://www.apache.org/foundation/how-it-works.html#pmc-chair
> - https://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers
>
> The PMC as a whole is the entity that oversees and leads the project and
> any PMC member can be approached as a representative of the committee. A
> list of Apache Cassandra PMC members can be found on:
> https://cassandra.apache.org/_/community.html
>

Re: EOL 2.1 series?

[Aaron Ploetz]

Speaking as a user with a few large clusters still running on 2.1, I think a 
final release of it with some additional fixes would be welcomed.  That being 
said, I thought we were holding off on EOLing 2.1 until 4.0 is released.  
Although, the timings probably don’t need to coincide.

In short, a (non-binding) final release of 2.1 is a good idea.

Thanks,

Aaron


> On Jan 7, 2019, at 8:01 PM, Michael Shuler  wrote:
> 
> It came to my attention on IRC a week or so ago, and following up on the
> ticket that someone asked if they should commit to 2.1, that developers
> have been actively ignoring the 2.1 branch. If we're not committing
> critical fixes there, even when we know they exist, I think it's time to
> just call it EOL an do one last release of the few fixes that did get
> committed. Comments?
> 
> Michael
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Google Season of Docs 2019 for Apache Cassandra

[Aaron Ploetz]

I’m willing to help as well.  Feel free to reach out!

Aaron Ploetz

> On Mar 12, 2019, at 8:37 PM, Rahul Singh  wrote:
> 
> Cool. I’m willing to help by taking sub sections of the overall effort. The 
> docs need a lot of TLC. Thanks ,
> 
> Rahul Singh
> Principal Architect | 1.202.390.9200 | rahul.si...@datastax.com
>> On Mar 12, 2019, 8:58 PM -0400, Ben Slater , 
>> wrote:
>> Hi Dinesh
>> 
>> Great idea. We should be able to find some Instaclustr people to help with
>> technical input (Stefan has already put his hand up).
>> 
>> I’m also happy to help with the application if that’s useful.
>> 
>> Cheers
>> Ben
>> 
>> ---
>> 
>> 
>> *Ben Slater*
>> *Chief Product Officer*
>> 
>> 
>> <https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr>
>> <https://www.linkedin.com/company/instaclustr>
>> 
>> Read our latest technical blog posts here
>> <https://www.instaclustr.com/blog/>.
>> 
>> This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
>> and Instaclustr Inc (USA).
>> 
>> This email and any attachments may contain confidential and legally
>> privileged information. If you are not the intended recipient, do not copy
>> or disclose its content, but please reply to this email immediately and
>> highlight the error to the sender and then immediately delete the message.
>> 
>> 
>> On Wed, 13 Mar 2019 at 08:12, Dinesh Joshi 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> I came across GSoD 2019[1]. This is different from GSoC and focuses on
>>> improving documentation for Open Source projects. I think this would be
>>> beneficial for Cassandra especially with 4.0 coming up. However, working
>>> with a technical writer will require a substantial time commitment from us
>>> to bring them up to speed.
>>> 
>>> Are there any volunteers to help guide the technical writer if Cassandra
>>> is picked as a project?
>>> 
>>> On a side note, we can put together the application on the Confluence
>>> wiki. I will create a page and if anybody is interested in helping out with
>>> putting together the application, please feel free to collaborate on it.
>>> 
>>> Thanks,
>>> 
>>> Dinesh
>>> 
>>> [1] https://developers.google.com/season-of-docs/docs/timeline
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Monthly community blog - thoughts?

[Aaron Ploetz]

I think this is an awesome idea, and I'm happy to help in any way that I
can.

Possible post topics:
-(new/existing) features
-common modeling practices
-community member "spotlight"
-tooling (Reaper, Medusa, K8s operator, etc...)

Thanks,

Aaron


On Fri, Oct 16, 2020 at 5:30 AM Horia Mocioi  wrote:

> Sounds good.
>
> How should we send suggestions? Via email or we can do it ourselves?
>
> Regards,
> Horia
>
> On Thu, Oct 15, 2020 at 11:58 PM Erick Ramirez  >
> wrote:
>
> > What a great idea! This is a good signal on how active the community is.
> >
> > I'm happy to help with proof-reading/reviews.
> >
> > P.S. The section on Harry contains HTML code. :)
> >
>

Re: New Cassandra website for review

[Aaron Ploetz]

Nice work, looks great!

Thanks,

Aaron


> On Feb 26, 2021, at 3:36 PM, Melissa Logan  wrote:
> 
> Hi all,
> 
> We are excited to share the almost-complete Cassandra website design
> (CASSANDRA-16115). Huge thanks to Lorina Poland, Anthony Grosso, Mick Semb
> Weaver, Josh Levy, Chris Thornett, Diogenese Topper, and a few others who
> contributed to this effort.
> 
> Note: There are a few updates to be made prior to launch, but we wanted to
> share to get initial input and signoff to begin the final port to Antora.
> 
> To be completed:
> 
>   - *Homepage: *The logos are placeholders -- they're being updated and
>   resized (pulled from case studies page).
>   - *Docs* will be added once 4.0 documentation is complete. Design
>   will match new site.
>   - *Case Studies * logos are being updated and resized, so ignore broken
>   links.
> 
> If you have case studies or resources -- or community photos --
> please reply to me and we'll add.
> 
> Site for review: https://cassandra.staged.apache.org/
> 
> https://issues.apache.org/jira/browse/CASSANDRA-16115
> 
> Melissa Logan

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [RELEASE] Apache Cassandra 4.0.0 released

[Aaron Ploetz]

So awesome.  Nice work, everyone!

Aaron


> On Jul 27, 2021, at 7:05 AM, Jean-Armel Luce  wrote:
> 
> Congrats all !!!
> 
>> Le mar. 27 juil. 2021 à 13:23, Benjamin Lerer  a écrit :
>> 
>> Thank you to all of those that contributed and helped out :-)
>> 
>> Le mar. 27 juil. 2021 à 07:05, Berenguer Blasi 
>> a
>> écrit :
>> 
>>> Congrats all! Amazing :-)
>>> 
>>> On 27/7/21 0:23, DuyHai Doan wrote:
 Congrats !!!
 
 3 years worth of waiting and finally released !!!
 
 
 
 On Tue, Jul 27, 2021 at 12:02 AM Ben Slater <
>> ben.sla...@instaclustr.com>
 wrote:
 
> Congratulations and thank you to everyone involved in getting 4.0
>>> released!
> It has been a very impressive community effort.
> 
> ---
> 
> 
> *Ben Slater**Chief Product Officer*
> 
> 
>    <
>>> https://twitter.com/instaclustr>
> 
> 
> Read our latest technical blog posts here
> .
> 
> This email has been sent on behalf of Instaclustr Pty. Limited
>>> (Australia)
> and Instaclustr Inc (USA).
> 
> This email and any attachments may contain confidential and legally
> privileged information.  If you are not the intended recipient, do not
>>> copy
> or disclose its content, but please reply to this email immediately
>> and
> highlight the error to the sender and then immediately delete the
>>> message.
> 
> 
> On Tue, 27 Jul 2021 at 07:34, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
> 
>> Super exciting, congratulations everybody. Great times ahead!
>> 
>> On Mon, 26 Jul 2021 at 22:19, Patrick McFadin 
> wrote:
>>> Wow. Just wow. Congratulations to everyone involved in this huge
>> milestone.
>>> On Mon, Jul 26, 2021 at 1:04 PM Brandon Williams 
>> wrote:
 The Cassandra team is pleased to announce the release of Apache
 Cassandra version 4.0.0.
 
 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 and binary distributions are available in our
 download section:
 
 http://cassandra.apache.org/download/
 
 This version is the initial release in the 4.0 series. As always,
 please pay attention to the release notes[2] and Let us know[3] if
> you
 were to encounter any problem.
 
 Enjoy!
 
 [1]: CHANGES.txt
 
 
> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0.0
 [2]: NEWS.txt
 
> 
>>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0.0
 [3]: https://issues.apache.org/jira/browse/CASSANDRA
 
 
>> -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Podcast Interviews for Feathercast

[Aaron Ploetz]

Sharan,

FWIW - Patrick and I are also working on putting together a Cassandra
podcast in the near future.  Perhaps we could work together?  Drop me a
message at aaron.plo...@datastax.com, and I'd be happy to set up some time
to discuss.

Thanks,

Aaron


On Wed, Apr 6, 2022 at 10:07 AM Sharan Foga  wrote:

> Hi All
>
> A quick update - I am working with someone on a potential first Cassandra
> related podcast. We are just looking at the questions and interview format
> etc to see how that could work.
>
> Thanks
> Sharan
>
> On 2022/04/02 11:43:32 Mick Semb Wever wrote:
> > >
> > >
> > > For those who are not familiar with FeatherCast
> > >  -  its the ASF's podcast channel
> that
> > > we generally use to help promote projects.
> > >
> > > Looking through the list of published content I see that there are a
> few
> > > interviews about Cassandra <
> https://feathercast.apache.org/?s=cassandra>
> > > but they are a few years old - so if anyone is interested in being
> > > interviewed then please let me know and we can set something up.
> > >
> > >
> >
> > This is an awesome opportunity. I recommend any and all committers to
> take
> > advantage of it.
> >
> > Chris / Melissa, when we do an 'inside cassandra … interview' for the
> > website, we should offer the contributor the opportunity to follow it up
> > with one of these podcasts.
> >
>

Re: CEP-15 multi key transaction syntax

[Aaron Ploetz]

Benedict,

I'm really excited about this feature.  I've been observing this
conversation for a while now, and I"m happy to add some thoughts.

We must balance the fact we cannot afford to do everything (yet), against
> the need to make sure what we do is reasonably intuitive (to both CQL and
> SQL users) and consistent – including with whatever we do in future.


I think taking small steps forward, to build a few complete features as
close to SQL as possible is a good approach.

question we are currently asking: do we want to have a more LWT-like
> approach... or do we want a more SQL-like approach
>

For years now we've been fighting this notion that Cassandra is difficult
to use.  Coming up with specialized syntax isn't going to bridge that
divide.  From a (new?) user perspective, the best plan is to stay as
consistent with SQL as possible.

I believe that is a MySQL specific concept. This is one problem with
> mimicking SQL – it’s not one thing!


Right?!?!  As if this needed to be more complex.

I think we have evidence that it is fine to interpret NULL as “false” for
> the evaluation of IF conditions.
>

Agree.  Null == false isn't too much of a leap.

Thanks for taking up the charge on this one.  Glad to see it moving forward!

Thanks,

Aaron



On Sun, Jun 12, 2022 at 10:33 AM bened...@apache.org 
wrote:

> Welcome Li, and thanks for your input
>
>
>
> > When I first saw the syntax, I took it for granted that the condition
> was evaluated against the state AFTER the updates
>
>
>
> Depending what you mean, I think this is one of the options being
> considered. At least, it seems this syntax is most likely to be evaluated
> against the values written by preceding statements in the batch, but not
> the statement itself (or later ones), as this could lead to nonsensical
> statements like
>
>
>
> BEGIN TRANSACTION
>
> UPDATE tbl SET v = 1 WHERE key = 1 AS tbl
>
> COMMIT TRANSACTION IF tbl.v = 0
>
>
>
> Where y is never 0 afterwards, so this never succeeds. I take it in this
> simple case you would expect the condition to be evaluated against the
> state prior to the statement (i.e. the initial state)?
>
>
>
> But we have a blank slate, so every option is available to us! We just
> need to make sure it makes sense to the user, even in uncommon cases.
>
>
>
> > The IF (Boolean expr) ABORT TRANSACTION would suffer less because users
> may tend to put the condition closer to the related SELECT statement.
>
>
>
> This is probably not going to matter in practice. The SELECTs all happen
> upfront no matter what the CQL might look like, and the UPDATE all happen
> only after the IF conditions are evaluated. This is all just a question of
> how the user expresses things.
>
>
>
> In future we may offer interactive transactions, or transactions that are
> multi-step, in which case this would be more relevant and could have an
> efficiency impact.
>
>
>
> > Would you consider allowing users to start a read-only transaction
> explicitly like BEGIN TRANSACTION READONLY?
>
>
>
> Good question. I would be OK with this, for sure, and will defer to the
> opinions of others here. There won’t be any optimisation impact, as we
> simply check if the transaction contains any updates, but some validation
> could be helpful for the user.
>
>
>
> > Finally, I wonder if the community would be interested in idempotency
> support.
>
>
>
> This is something that has been considered, and that Accord is able to
> support (in a couple of ways), but as an end-to-end feature this requires
> client support and other scaffolding that is not currently
> planned/scheduled. The simplest (least robust) approach is for the server
> to include the transaction’s identifier in its timeout, so that it be
> queried by the client to establish if it has been made durable. This should
> be quite easy to deliver on the server-side, but would require some
> application or client integration, and is unreliable in the face of
> coordinator failure (so the transaction id is unknown to the client). The
> more complete approach is for the client to include an idempotency token in
> its submission to the server, and for C* to record this alongside the
> transaction id, and for some bounded time window to either reject
> re-submissions of this token or to evaluate it as a no-op. This requires
> much tighter integration from the clients, and more work server-side.
>
>
>
> Which is simply to say, this is on our radar but I can’t make promises
> about what form it will take, or when it will arrive, only that it has been
> planned for enough to ensure we can achieve it when resources permit.
>
>
>
> *From: *Li Boxuan 
> *Date: *Sunday, 12 June 2022 at 16:14
> *To: *dev@cassandra.apache.org 
> *Subject: *Re: CEP-15 multi key transaction syntax
>
> Correcting my typo:
>
>
>
> >  I took it for granted that the condition was evaluated against the
> state before the updates
>
>
>
> I took it for granted that the condition was evaluated against the state
> AFTER the upda

The Apache Cassandra(R) Corner Podcast

[Aaron Ploetz]

After some recent discussions and ultimately guidance from Mick, I have
made some adjustments to bring the Apache Cassandra® Corner (formerly known
as the "Cassandra Corner") podcast more into alignment with the Apache
Cassandra® project guidelines and standards.  I have sent the credentials
for Anchor (the central location for the podcast) to Mick, and I will post
all future episodes with a 72 hour staging period for approval.

Link to next episode:

Ep5 - Melissa Logan (Constantia)
https://drive.google.com/file/d/1E4zQmHK4eU635JFjqEDEjVrth14eeVBK/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
on Thursday June 30th.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

Thanks everyone!

Aaron Ploetz

New episode of the Apache Cassandra(R) Corner Podcast

[Aaron Ploetz]

Link to next episode:

Ep6 - Jeff Beck (SmartThings)
https://drive.google.com/file/d/1_dhnMUlSF_8qByHdcoWQc0GD0rhsZjVf/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
on Thursday, July 28th.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

Thanks everyone!

Aaron Ploetz

New episode of the Apache Cassandra(R) Corner Podcast!

[Aaron Ploetz]

Link to next episode:

Ep7 - Ekaterina Dimitrova (Apache Cassandra committer)
https://drive.google.com/file/d/1xgwHOdufJAEwjlAluJZP2XwfbGpFWEwv/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, August 22nd.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I have recording sessions scheduled with:
- Otavio Santana (Java Champion and Open Source Committer w/ the Eclipse
Foundation)
- Sarma Pydipally (Udemy Instructor, Principal Engineer w/ Verizon)

So I should have a good flow of episodes for the next couple of weeks.

Thanks everyone!

Aaron Ploetz

Re: [DISCUSS] CEP-20: Dynamic Data Masking

[Aaron Ploetz]

Some thoughts on this one:

In a prior job, we'd give app teams access to a single keyspace, and two
roles: a read-write role and a read-only role.  In some cases, a
"privileged" application role was also requested.  Depending on the
requirements, I could see the UNMASK permission being applied to the RW or
privileged roles.  But if there's a problem on the table and the operators
go in to investigate, they will likely use a SUPERUSER account, and they'll
see that data.

How hard would it be for SUPERUSERs to *not* automatically get the UNMASK
permission?

I'll also echo the concerns around masking primary key components.  It's
highly likely that certain personal data properties would be used as a
partition or clustering key (ex: range query for people born within a
certain timeframe).  In addition to the "breaks existing" concern, I'm
curious about the challenges around getting that to work with the current
primary key implementation.

Does this first implementation only apply to payload (non-key) columns?
The examples in the CEP currently do not show primary key components being
masked.

Thanks,

Aaron


On Tue, Aug 23, 2022 at 6:44 AM Henrik Ingo 
wrote:

> On Tue, Aug 23, 2022 at 1:10 PM Andrés de la Peña 
> wrote:
>
>> One thought: The way the CEP is currently written, it is only possible to
>>> mask a column one way. You can only define one masking function for a
>>> column, and since you use the original column name, you could only return
>>> one version of it in the result set, even if you had a way to define
>>> several functions.
>>>
>>
>> Right, it's one single type of mapping per the column, declared on
>> CREATE/ALTER TABLE statements. Also, users can manually specify their own
>> masking function in SELECT statements if they have permissions for seeing
>> the clear data.
>>
>> For those cases where the data is automatically masked for an
>> unprivileged user, I don't see the use of including different types of
>> masking for the same column into the same result set. Instead, we might be
>> interested on having different types of masking associated to different
>> roles. We could do so with dedicated CREATE/DROP/LIST MASK statements,
>> instead of using the CREATE/ALTER/DESCRIBE TABLE statements. That CREATE
>> MASK statement would associate a masking function to a column and role.
>> However, I'm not sure we need that type of granularity instead of the
>> simplicity of attaching the masking to the column declaration. wdyt?
>>
>>
>>
> My gut feeling likewise is that this adds complexity but little value.
>
>>
>>>
>
> --
>
> Henrik Ingo
>
> +358 40 569 7354 <358405697354>
>
> [image: Visit us online.]   [image: Visit us
> on Twitter.]   [image: Visit us on
> YouTube.]
> 
>   [image: Visit my LinkedIn profile.]
> 
>

Re: [DISCUSS] CEP-20: Dynamic Data Masking

[Aaron Ploetz]

>
> Applying this should prevent querying on a field, else you could leak its
> contents, surely?
>

In theory, yes.  Although I could see folks doing something like this:

SELECT COUNT(*) FROM patients
WHERE year_of_birth = 2002
AND date_of_birth >= '2002-04-01'
AND date_of_birth < '2002-11-01';

In this case, the rows containing the masked key column(s) could be
filtered on without revealing the actual data.  But again, that's probably
better for a "phase 2" of the implementation.

Agreed on not being a queryable field. That would also preclude secondary
> indexing, right?


Yes, that's my thought as well.

On Tue, Aug 23, 2022 at 12:42 PM Derek Chen-Becker 
wrote:

> Agreed on not being a queryable field. That would also preclude secondary
> indexing, right?
>
> On Tue, Aug 23, 2022 at 11:20 AM Benedict  wrote:
>
>> Applying this should prevent querying on a field, else you could leak its
>> contents, surely? This pretty much prohibits using it in a clustering key,
>> and a partition key with the ordered partitioner - but probably also a
>> hashed partitioner since we do not use a cryptographic hash and the hash
>> function is well defined.
>>
>> We probably also need to ensure that any ALLOW FILTERING queries on such
>> a field are disabled.
>>
>> Plausibly the data could be cryptographically jumbled before using it in
>> a primary key component (or permitting filtering), but it is probably
>> easier and safer to exclude for now…
>>
>> On 23 Aug 2022, at 18:13, Aaron Ploetz  wrote:
>>
>> 
>> Some thoughts on this one:
>>
>> In a prior job, we'd give app teams access to a single keyspace, and two
>> roles: a read-write role and a read-only role.  In some cases, a
>> "privileged" application role was also requested.  Depending on the
>> requirements, I could see the UNMASK permission being applied to the RW or
>> privileged roles.  But if there's a problem on the table and the operators
>> go in to investigate, they will likely use a SUPERUSER account, and they'll
>> see that data.
>>
>> How hard would it be for SUPERUSERs to *not* automatically get the UNMASK
>> permission?
>>
>> I'll also echo the concerns around masking primary key components.  It's
>> highly likely that certain personal data properties would be used as a
>> partition or clustering key (ex: range query for people born within a
>> certain timeframe).  In addition to the "breaks existing" concern, I'm
>> curious about the challenges around getting that to work with the current
>> primary key implementation.
>>
>> Does this first implementation only apply to payload (non-key) columns?
>> The examples in the CEP currently do not show primary key components being
>> masked.
>>
>> Thanks,
>>
>> Aaron
>>
>>
>> On Tue, Aug 23, 2022 at 6:44 AM Henrik Ingo 
>> wrote:
>>
>>> On Tue, Aug 23, 2022 at 1:10 PM Andrés de la Peña 
>>> wrote:
>>>
>>>> One thought: The way the CEP is currently written, it is only possible
>>>>> to mask a column one way. You can only define one masking function for a
>>>>> column, and since you use the original column name, you could only return
>>>>> one version of it in the result set, even if you had a way to define
>>>>> several functions.
>>>>>
>>>>
>>>> Right, it's one single type of mapping per the column, declared on
>>>> CREATE/ALTER TABLE statements. Also, users can manually specify their own
>>>> masking function in SELECT statements if they have permissions for seeing
>>>> the clear data.
>>>>
>>>> For those cases where the data is automatically masked for an
>>>> unprivileged user, I don't see the use of including different types of
>>>> masking for the same column into the same result set. Instead, we might be
>>>> interested on having different types of masking associated to different
>>>> roles. We could do so with dedicated CREATE/DROP/LIST MASK statements,
>>>> instead of using the CREATE/ALTER/DESCRIBE TABLE statements. That CREATE
>>>> MASK statement would associate a masking function to a column and role.
>>>> However, I'm not sure we need that type of granularity instead of the
>>>> simplicity of attaching the masking to the column declaration. wdyt?
>>>>
>>>>
>>>>
>>> My gut feeling likewise i

New episode of the Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to next episode:

Ep8 - Sarma Pydipally (Udemy instructor, open source dev)
https://drive.google.com/file/d/15-qRcWOyLwQi5lsY06rUYBdLViXGk_xs/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Wednesday, August 31st.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

For my guest pipeline, I have recording sessions scheduled with:
- Otavio Santana (Java Champion and Open Source Committer w/ the Eclipse
Foundation)


Thanks everyone!

Aaron Ploetz

New episode of The Apache Cassandra Corner(R)

[Aaron Ploetz]

Link to next episode:

Ep9 - Otavio Santana (Java Champion, open source dev)
https://drive.google.com/file/d/1NYk1zCyyHErkuyrJsFGannBx0NAYreea/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, September 12th.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

As for my guest pipeline, I do have a gap coming up.  So if you or someone
you know would be a great guest, please let me know!

Thanks, everyone!

Aaron Ploetz

New episode of The Apache Cassandra Corner(R)

[Aaron Ploetz]

Link to next episode:

Ep10 - Cheng Wang and Jordan West (Netflix)

https://drive.google.com/file/d/1_f-0vTv-ZDZEcLSgqW8b8NQbAjmlQM2Q/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Friday (night), October 14th.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

Thanks, everyone!

Aaron

New episode of The Apache Cassandra(R) Corner

[Aaron Ploetz]

Link to next episode:

Ep11 - Mick Semb Weaver (Apache Cassandra PMC Chair)

https://drive.google.com/file/d/16bSw-hJVVOkIzTEg86KYUMT9g9Nm-X5B/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Friday (night), October 14th.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

Thanks, everyone!

Aaron

New episode of The Apache Cassandra(R) Corner

[Aaron Ploetz]

Link to next episode:

Ep12 - Derek Chen-Becker (AWS Sr. Engineer & open source dev)

https://drive.google.com/file/d/1JH7oQCtvVFUqH1Lhlo66dvW2Fzodif5H/view?usp=sharing

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Wednesday (evening), November 2nd.  I'm giving this one a little extra
time, as Amazon's PR folks would like to give it a listen, as well.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

Thanks, everyone!

Aaron

New episode of The Apache Cassandra(R) Corner

[Aaron Ploetz]

Link to next episode:

Ep13 - Alexa Simon (Realeyes Sr. Data Engineer)

https://drive.google.com/file/d/17vVbAirAJABH4ZbNS-4Yk-eeUbQCyTWd/view?usp=share_link

(You may have to download it to listen)

It will remain in staging for 72 hours, going live (assuming no objections)
by Friday (afternoon), November 11th.

If anyone should have any questions, comments, or if you want to be a
guest, please reach out to me.

Thanks, everyone!

Aaron

Re: Welcome Jaydeepkumar Chovatia as Cassandra committer

[Aaron Ploetz]

Congratulations Jaydeep!


> On Apr 30, 2025, at 8:18 AM, Paulo Motta  wrote:
> 
> Congratulations Jaydeep!