Re: Welcome Patrick McFadin as Cassandra Committer

[Christopher Bradford]

Congrats Patrick! Well done.

On Thu, Feb 2, 2023 at 10:44 AM Aaron Ploetz  wrote:

> 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
>>>
>> --

Christopher Bradford

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

[Christopher Bradford]

Hi Dinesh,

This is awesome. I'm certain myself and the folks on the K8ssandra project
will be following along with this ticket. I had a few questions after
looking at the JIRA and attached PR:


   1. Is there an expectation that this would be used alongside internode
   and client TLS? Would the certificates be the same, different, or is that
   an implementation detail for the specific deployment to determine?
   2. For some reason I'm having trouble understanding the internode
   authentication portion of this ticket (authenticating a client with a
   certificate makes sense vs just authenticating the connection). Why is this
   needed on top of the connection-level TLS we have now?
   3. When an operator or DBA is looking to add a new identity is that just
   handled as part of the new CQL statement or is there some certificate
   management required on the nodes? I assume it's just the CA that needs to
   be placed on the nodes to establish trust in the certificate itself then
   authz happening within C* after determining the certificate can be trusted,
   but want to be certain.
   4. As a minor nit, should we include static certificates in the test
   data? I see they expire in 2033 which is a fair way off, but I wonder if it
   would make sense to generate the certificates as part of the test setup.

Thanks for the contribution (along with the ping on dev@) and I look
forward to seeing this functionality.

Cheers,
~Chris

Christopher Bradford



On Fri, Jun 2, 2023 at 11:03 AM Dinesh Joshi  wrote:

> Hi dev@,
>
> We're planning to add mTLS client authentication as well as internode
> authentication in CASSANDRA-18554. While this is all backward compatible,
> we thought it would be a good idea to notify the dev list. If anybody is
> interested please take a look at the JIRA.
>
> Thanks,
>
> Dinesh

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

[Christopher Bradford]

hes *spiffe://example.com/payments/cassandra/*
   <http://example.com/payments/cassandra/*>.* My initial reading here is
   that it is not possible at this time. We could use a common workload
   identifier across all nodes in the cluster (ie
*spiffe://example.com/payments/cassandra
   <http://example.com/payments/cassandra>*) then we would only need a
   single certificate in the trust store with the associated identity. This
   leads to my next question...
   4. From a documentation perspective, how would you describe a reference
   implementation? I think the project could benefit from a reference
   configuration including mTLS for clients and nodes with separate
   certificates for all components / nodes alongside a sample SPIFFE identity.
   (This question may be a bit outside of scope for the particular ticket /
   feature, but it's something to noodle on)

Again thank you for the contribution and patience as I work through the
code and mental model mapping this on top of my existing C* / TLS knowledge.

Cheers,
~Chris

Christopher Bradford



On Fri, Jun 2, 2023 at 2:57 PM Dinesh Joshi  wrote:

>
>1. Is there an expectation that this would be used alongside internode
>and client TLS? Would the certificates be the same, different, or is that
>an implementation detail for the specific deployment to determine?
>
>
> I am not sure what you mean by this would be used alongside internode and
> client TLS? The mutual TLS authentication allows the server to authenticate
> the client's identity using a client TLS certificate. The authenticators
> we're adding enable this functionality. There isn't an expectation that the
> same certificates be used. In fact, clients should not use the same
> certificates as the internode.
>
>
>1. For some reason I'm having trouble understanding the internode
>authentication portion of this ticket (authenticating a client with a
>certificate makes sense vs just authenticating the connection). Why is this
>needed on top of the connection-level TLS we have now?
>
>
> Current connection-level TLS only secures the TLS connection. It doesn't
> authenticate the peer. This adds the ability to authenticate the peer in
> addition to securing the TLS connection.
>
>
>1. When an operator or DBA is looking to add a new identity is that
>just handled as part of the new CQL statement or is there some certificate
>management required on the nodes? I assume it's just the CA that needs to
>be placed on the nodes to establish trust in the certificate itself then
>authz happening within C* after determining the certificate can be trusted,
>but want to be certain.
>
>
> Each deployment is different so certificate management isn't scope of the
> database itself. However, the operator can rotate the certificates using an
> external agent and Cassandra will pick them up through SSL hot reloading.
> We don't just rely on a CA trusting the client certificate, we extract the
> identity from the certificate (for example: SPIFFE) and ensure that it is
> allowed to access the cluster. This means someone can't just obtain a
> certificate signed by a CA that Cassandra cluster trusts and connect to it.
>
>
>1. As a minor nit, should we include static certificates in the test
>data? I see they expire in 2033 which is a fair way off, but I wonder if it
>would make sense to generate the certificates as part of the test setup.
>
> Thanks for the feedback!
>

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

[Christopher Bradford]

Looping back to the discussion around keystore usage and shared vs
individual identity. I understand the approach of having a single identity
shared by all nodes in the cluster. Including the entire response here, but
want to focus on the first line.

*The reason we use the keystore is that the node extracts its own identity
> and expects other nodes in the cluster to share the same identity.* This
> default behavior makes it easy to avoid configuring individual identities
> of nodes in the cluster. It's critical to recognize that if we had a
> separate identity for each node in the cluster, then we would need to
> update all nodes in the cluster when a new node is added or removed. This
> way all nodes in the cluster can have a shared identity while
> simultaneously preventing unnecessary operational pain of adding and
> removing identities each time a node is added or removed from the cluster.

(emphasis mine)

It is surprising to me that we load the identity from the keystore vs
explicitly setting an expected value in cassandra.yaml. I get that an error
is thrown if the identity doesn't match those of other nodes in the
cluster, but does it make sense to prevent startup should the value in the
keystore deviate from a (currently nonexistent) value in cassandra.yaml?

It feels like there is a parallel to how we set the cluster name in
cassandra.yaml even though the value is also present within our local
sstables and leads to startup errors should they differ.

Christopher Bradford



On Fri, Jun 30, 2023 at 4:09 PM Jeremiah Jordan 
wrote:

> I don’t think users necessarily need to be able to update their own
> identities.  I just don’t want to have to use the super user role.  The
> super user role has all power over all things in the data base.  I don’t
> want to have to give that much power to the person who manages identities,
> I just want to give them the power to manage identities.
>
> Jeremiah Jordan
> e. jerem...@datastax.com
> w. www.datastax.com
>
>
>
> On Jun 30, 2023 at 1:35:41 PM, Dinesh Joshi  wrote:
>
>> Yuki, Jeremiah both are fair points. The mental model we're using for
>> mTLS authentication is slightly different.
>>
>> In your model you're treating the TLS identity itself to be similar to
>> the password. The password is the 'shared secret' that currently needs
>> to be rotated by the user that owns the account therefore necessitating
>> the permission to update their password. But that is not the case with
>> TLS certificates and mTLS identities.
>>
>> The model we're going for is different. The identity is provisioned for
>> an account by a super user. This is more locked down and the user can
>> still rotate their own certificates but not change the identity
>> associated with their account without a super user.
>>
>> Once provisioned, a user does not need rotate the identity itself. They
>> only need to obtain fresh certificates as their certificates near
>> expiry. This requires no updates on the database unlike passwords.
>>
>> We could extend this functionality in the future to allow users to
>> change their own identity. Nothing here prevents that.
>>
>> thanks,
>>
>> Dinesh
>>
>>
>>
>> On 6/29/23 08:16, Jeremiah Jordan wrote:
>>
>> I like the idea of extending CREATE ROLE rather than adding a brand new
>>
>> ADD IDENTITY syntax.  Not sure how that can line up with one to many
>>
>> relationships for an identity, but maybe that can just be done through
>>
>> role hierarchy?
>>
>>
>> In either case, I don’t think IDENTITY related operations should be tied
>>
>> to the super user flag. They should be tied to either existing role
>>
>> permissions, or a brand new permissions about IDENTITY.  We should not
>>
>> require that end users give the account allowed to make IDENTITY changes
>>
>> super user permission to do what ever they want across the whole database.
>>
>>
>> On Jun 28, 2023 at 11:48:02 PM, Yuki Morishita >
>> <mailto:mor.y...@gmail.com>> wrote:
>>
>> > Thinking more about "CREATE ROLE" permission, if we can extend CREATE
>>
>> > ROLE/ALTER ROLE statements, it may look streamlined:
>>
>> >
>>
>> > I don't have the good example, but something like:
>>
>> > ```
>>
>> > CREATE ROLE dev WITH LOGIN = true AND IDENTITIES = {'spiffe://xxx'};
>>
>> > ALTER ROLE dev ADD IDENTITY 'xxx';
>>
>> > LIST ROLES;
>>
>> > ```
>>
>> >
>>
>> > This requires a role to identitie

Support for networking via identity instead of IP

[Christopher Bradford]

Hello C* Dev list,

While thinking through some ways to span clouds / Kubernetes clusters I
found some approaches not possible (or significantly difficult) due to how
we use IP addresses instead of hostnames. This lead to the creation of
CASSANDRA-15823 <https://issues.apache.org/jira/browse/CASSANDRA-15823>
along with this message to spark some discussion in this space. The body of
the ticket is a little lengthy but goes into the background a bit more.

Additionally while in discussions with some other C* users there is
apparently a bit of pain around our use of IPs instead of hostnames. We
were about how cass-operator uses DNS for seed node discovery and they were
excited about an uptick in hostname / DNS usage instead of a list of IP
addresses.

Any thoughts about this proposal? What are some pitfalls that should be
considered?

Thanks,
~Chris

Christopher Bradford

Re: Support for networking via identity instead of IP

[Christopher Bradford]

I wasn’t sure if this was CEP material or not. I don’t mind migrating it
that direction instead of a JIRA.

Thanks!

On Tue, May 19, 2020 at 11:19 PM Dinesh Joshi  wrote:

> Hi Chris,
>
> I skimmed through your proposal and it looks interesting. We can
> definitely discuss this but at the moment we’re iterating on releasing 4.0
> so your proposal may not get a whole lot of traction. We also have a new
> process to propose largish changes like you suggested called CEP (Cassandra
> Enhancement Process). You don’t have to formally write up a doc if you’re
> looking to just bounce ideas off of folks in the mailing list. Just making
> you aware in case you didn’t know.
>
> Cheers,
>
> Dinesh
>
> > On May 19, 2020, at 7:05 PM, Christopher Bradford 
> wrote:
> >
> > Hello C* Dev list,
> >
> > While thinking through some ways to span clouds / Kubernetes clusters I
> > found some approaches not possible (or significantly difficult) due to
> how
> > we use IP addresses instead of hostnames. This lead to the creation of
> > CASSANDRA-15823 <https://issues.apache.org/jira/browse/CASSANDRA-15823>
> > along with this message to spark some discussion in this space. The body
> of
> > the ticket is a little lengthy but goes into the background a bit more.
> >
> > Additionally while in discussions with some other C* users there is
> > apparently a bit of pain around our use of IPs instead of hostnames. We
> > were about how cass-operator uses DNS for seed node discovery and they
> were
> > excited about an uptick in hostname / DNS usage instead of a list of IP
> > addresses.
> >
> > Any thoughts about this proposal? What are some pitfalls that should be
> > considered?
> >
> > Thanks,
> > ~Chris
> >
> > Christopher Bradford
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --

Christopher Bradford

Re: Cassandra Kubernetes SIG - status update

[Christopher Bradford]

It sounds like he just included the agent jar which has this class on the
CLASSPATH. This feels like an enhancement for the definitions config
builder uses to allow for configuration of the seed provider.

On Tue, Aug 18, 2020 at 11:00 PM Cyril Scetbon 
wrote:

> Hey John,
>
>
>
> I’m also in the middle of evaluating this image as I want to test
> cassandra 4.0-beta1 and am trying to avoid having to handle changes at the
> configuration level (deprecated/renamed parameters for instance). I also
> have an issue with the fact the seed_provider class is not parameterized.
> See https://github.com/datastax/cass-config-definitions/issues/19 <
> https://github.com/datastax/cass-config-definitions/issues/19>.
>
>
>
> Did you happen to fork the project with that change ?
>
>
>
> Thanks
>
> —
>
> Cyril Scetbon
>
>
>
> > On Aug 5, 2020, at 11:51 PM, John Sanda  wrote:
>
> >
>
> > cass-config-builder configures Cassandra to
>
> > use org.apache.cassandra.locator.K8SeedProvider. This class however is
>
> > defined in management-api-for-apache-cassandra
>
> > <https://github.com/datastax/management-api-for-apache-cassandra <
> https://github.com/datastax/management-api-for-apache-cassandra>>, i.e.,
>
> > the DataStax management sidecar. I am not using the management sidecar
> yet,
>
> > but updated my C* image to include the agent JAR which contains the
>
> > K8SeedProvider class. I am still trying to iron out some of the wrinkles.
>
>
>
> --

Christopher Bradford

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[Christopher Bradford]

uster back up follows expected startup procedures

Road Map / Inflight

   1.

   Repair
   1.

  Reaper integration
  2.

   Backups
   1.

  Velero integration
  2. Medusa integration
   3.

   Advanced Networking via sidecar
   1.

  Combination of proxy sidecars (a la Envoy) to allow for persistent IP
  addresses despite Kubernetes' best efforts to shuffle them.
  4.

   Single pod canary deployments
   5.

   Platform Certification
   1. VMware Project Pacific

  2.

  Rancher Kubernetes Engine (K3s)
  6.

   Documentation
   1.

  Multi-region
  2.

  Multi-cloud
  3.

  Additional ingress providers
  1. Voyager
 2. HAProxy
 3. Gloo
 4. Ambassdor
 5. Envoy
 6. NGINX Ingress Controller
 4.

  Additional storage class references
  1.

 OpenEBS
 7.

   Cassandra Enhancements
   1.

  [#CASSANDRA-15823] Support for networking via identity instead of IP
  - ASF JIRA <https://issues.apache.org/jira/browse/CASSANDRA-15823>


If there are further questions about the project, codebase, architecture,
etc. the team would be happy to dive in to the details and discuss more.

Cheers,
~Chris

Christopher Bradford



On Mon, Sep 28, 2020 at 12:19 PM Patrick McFadin  wrote:

> I can agree with that Ben. Franck did a good job of outlining CassKop.
> Somebody from the cass-operator will be posting something similar and we
> can keep it on the mailing list.
>
> Patrick
>
> On Sun, Sep 27, 2020 at 2:16 PM Ben Bromhead  wrote:
>
> > Thanks Frank and Stefan.
> >
> > @Patrick great suggestion and worthwhile getting everything on the table.
> >
> > One minor change I would advocate for. The SIG has been great to iterate
> > and interact on the details, but I really think this conversation given
> the
> > nature of the content needs to be on the mailing list. The mailing list
> is
> > really our system of record and the most accessible.
> >
> > It gives folk time to think and digest, it's asynchronous, easily
> > searchable and let's be honest, the majority of stakeholders in this are
> > not US based, so the timing issue then goes away and makes it easier for
> > people to participate in. I feel like we've made a lot more progress by
> > simply having this discussion here.
> >
> > So instead of a presentation, maybe just an email to the ML addressing
> the
> > headings that Patrick identified?
> >
> >
> > On Fri, Sep 25, 2020 at 7:55 AM Stefan Miklosovic <
> > stefan.mikloso...@instaclustr.com> wrote:
> >
> > > Hi,
> > >
> > > Patrick's suggestion seems good to me.
> > >
> > > I won't go into specifics here as I need to genuinely prepare for
> > > this. It is quite hard to dig deep into the solutions of others and
> > > bring some constructive criticism because it takes a lot of time to
> > > study it and everybody has some "why's" behind it.
> > >
> > > To summarize my goals and concerns:
> > >
> > > 1) We should be as much "Kubernetes operator idiomatic" as possible.
> > > Industry standards, no custom brain-child of this or that group
> > > because they think it is just cool or they just didn't know any
> > > better. I do NOT say it is like that right now, I just want to be
> > > ruthless here as much as possible when it comes to functionality and
> > > why it is done like that. It is awesome that we have already something
> > > latest (thanks to John) and it adheres to the latest releases. I
> > > personally had a hard time to keep up with all the releases, once I
> > > finished something and I aligned it, after a week or two there was
> > > already another one where things were different, it is a very
> > > fast-moving space and I hope that by time we develop something it will
> > > not be obsolete.
> > >
> > > 2) It may be easier said than done but it is guaranteed that people
> > > get emotional, it's their precious etc, so please let's go into this
> > > with good intentions, not trying to push one solution over the other
> > > just because they would like to see it there ... I will have an
> > > equally hard time to comply with this point. My plan is to explain
> > > what is _wrong_ with our solution. Where we made mistakes and what
> > > should be done differently but it is "too late" etc. It is quite hard
> > > to describe your work and all effort in this light but without telling
> > > what is wrong we can not decide what is go

Re: [DISCUSS] Next steps for Kubernetes operator SIG

[Christopher Bradford]

Hello Franck,

This sounds like a great plan. We would love to expand the group of
contributors and work towards getting the combined efforts pulled into the
Apache Cassandra project proper. The list of items listed here are all wins
in our book (and we've even said how much we enjoyed the CassKop labelling
interface).

Cheers,
~Chris

Christopher Bradford



On Fri, Oct 2, 2020 at 11:35 AM  wrote:

> An update on Orange's point of view following the recent emails:
>
> If we were a newly interested party in running C* in K8s, we would use
> Cass-operator as it comes from Datastax.
>
> The logic would then be that the community embraces it and thanks Datastax
> for offering it!
>
> So, on Orange side, we propose to discuss with Datastax how to best merge
> Casskop's features in Cass-operator.
> These features are:
> - nodes labelling to map any internal architecture (including network
> specific labels to muti-dc setup)
> - volumes & sidecars management (possibly linked to PodTemplateSpec)
> - backup & restore (we ruled out velero and can share why we went with
> Instaclustr but Medusa could work too)
> - kubectl plugin integration (quite useful on the ops side without an
> admin UI)
> - multiCassKop evolution to drive multiple cass-operators instead of
> multiple casskops (this could remain Orange internal if too specific)
>
> We could decide at the end of these discussions the best way forward.
> Orange could make PRs on cass-operator, but only if we agree we want the
> functionalities :)
>
> If we can sort it out we could end up with a pretty neat operator.
>
> We share a common architecture (operator-sdk), start to know each other
> with all these meetings so it should be possible if we want to!
>
> Would that be ok for the community and Datastax?
>
>
>
> > On 2 Oct 2020, at 14:52, Joshua McKenzie  wrote:
> >
> > What are next steps here?
> >
> > Maybe we collectively put a table together w/the 2 operators and a list
> of
> > features to compare and contrast? Enumerate the frameworks / dependencies
> > they have to help form a point of view about the strengths and weaknesses
> > of each option?
> >
> >
> > On Tue, Sep 29, 2020 at 10:22 PM, Christopher Bradford <
> bradfor...@gmail.com
> >> wrote:
> >
> >> Hello Dev list,
> >>
> >> I'm Chris Bradford a Product Manager at DataStax working with the
> >> cass-operator team. For background, we started down the path of
> developing
> >> an operator internally to power our C*aaS platform, Astra. Care was
> taken
> >> from day 1 to keep anything specific to this product at a layer above
> >> cass-operator so it could solely focus on the task of operating
> Cassandra
> >> clusters. With that being said, every single cluster on Astra is
> >> provisioned and operated by cass-operator. The value of an advanced
> >> operator to Cassandra users is tremendous so we decided to open source
> the
> >> project (and associated components) with the goal of building a
> community.
> >> It absolutely makes sense to offer this project and codebase up for
> >> donation as a standard / baseline for running C* on Kubernetes.
> >>
> >> Below you will find a collection of cass-operator features,
> >> differentiators, and roadmap / inflight initiatives. Table-stakes
> >> Must-have functionality for a C* operator
> >>
> >> -
> >>
> >> Datacenter provisioning
> >> -
> >>
> >> Schedule all pods
> >> -
> >>
> >> Bootstrap nodes in the appropriate order
> >> -
> >>
> >> Seeds
> >> -
> >>
> >> Across racks
> >> -
> >>
> >> etc.
> >> -
> >>
> >> Uniform configuration
> >> -
> >>
> >> Scale-up
> >> -
> >>
> >> Add new nodes in a balanced manner across rack
> >> -
> >>
> >> Scale-down
> >> -
> >>
> >> Remove nodes one at a time across racks
> >> -
> >>
> >> Node recovery
> >> -
> >>
> >> Restart process
> >> -
> >>
> >> Reschedule instance (IE replace node)
> >> - Replace instance
> >> -
> >>
> >> Specific workflows for seed node replacements
> >> -
> >>
> >> Multi-DC / Multi-Rack
> >> -
> >>
> >> Multi-Region / Multi-K8s Cluster
> >> -
> >>
> >> Note this requires support at a networking layer for pod to pod IP

Re: Kubernetes Operator: Can We Preserve CassKop's Flexibility?

[Christopher Bradford]

Hey Tom,

You make some great points. I agree that there is an ecosystem of tooling
surrounding cass-operator, but those tools are narrowly focused on
particular tasks. Ideally, as community iniatives like CEP-1
<https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224>
graduate, they can replace these components where appropriate. Right now
the documentation for cass-operator exists in a few separate directories
under the Github repo. Guidance around specific topics and some more
reference material is sorely needed. There is currently an effort underway
to organize existing documentation and build out a platform for new
content.

In your message you reference support for a pre-run script. We have this
functionality in cass-operator via the spec.podTemplateSpec.initContainers
field. The cass-confg-builder container is prepended to this list ensuring
that all rendered configuration files are available on disk for any
subsequent containers to modify / leverage. There are some cass-operator
users that schedule their own containers to pull secrets from external
systems like Vault and inject them into the configs.

~Chris

Christopher Bradford



On Wed, Oct 7, 2020 at 11:00 PM Cyril Scetbon  wrote:

> Thank you Tom for your support, as one of the main contributors of CassKop
> I’m happy to see that the efforts we put in it to try to support as many
> configurations as possible is well appreciated.
>
> When we first started to talk about creating a kubernetes operator we
> always mentioned the features that we added and the importance of trying to
> fulfill the needs of every user. All those choices have a reason, a
> situation that happened on production, a configuration that we used to
> apply to some of our clusters or a situation that could potentially happen
> and that we needed to overcome. An example is the fact that IPs could
> change when a kubernetes node restarts, and possibly IPs could be exchanged
> between 2 nodes of the same cluster. We then implemented a detection
> algorithm  that when it sees it happening tries to restart pods which
> should get new IPs and solve the problem
> https://orange-opensource.github.io/casskop/docs/3_configuration_deployment/9_advanced_configuration#cross-ip-management
>
> The features we tried to add solved use cases that happened on production
> or that could happen due to the environment and we tried to make it as
> simple and intuitive as possible. We put also a lot of efforts in the
> documentation which is not perfect but serves the purpose of explaining and
> detailing how to use CassKop.
>
> Soon, when we start talking about porting our features, we’ll of course
> support the importance of making it opened (tbh we had in mind to make it
> supported by any recent Cassandra versions and even ScyllaDB) as much as
> possible, simple, configurable and adaptable if possible. Of course not all
> versions are supported even by CassKop cause we make some Jolokia calls and
> if the JMX bean change some important operations could stop working (We
> check that a datacenter has no data replicated to it before decommissioning
> <
> https://orange-opensource.github.io/casskop/docs/5_operations/1_cluster_operations#updatescaledown>
> it for instance).
>
> I had a few discussions with some of the cass-operator developers and I
> think we understood each other and know that in order for it to be adopted
> and the work to be fruitful no feature should be lost on the way and if
> there is a better way to do things we’ll find it together. Orange also uses
> CassKop and will keep using it as long as the crucial features are not
> available. We’ll also have to find a way to migrate from CassKop to
> Cass-operator without breaking everything. But let’s start walking before
> running 😉
>
> —
> Cyril Scetbon
>
> > On Oct 7, 2020, at 2:23 PM, Tom Offermann 
> wrote:
> >
> > I've been following the discussion about Kubernetes operators with a
> great
> > deal of interest. At New Relic, we're about to move our Cassandra
> Clusters
> > from bare-metal hosts in our datacenters to Kubernetes clusters in AWS,
> so
> > we've been looking closely at the current operators.
> >
> > Our goals:
> >
> > * Don't write our own operator.
> >
> > * Choose the community standard, if possible. If not possible, choose an
> > operator with active development, usage, and community.
> >
> > * Choose an operator that can work with our existing way of managing
> > clusters. Most significantly, at New Relic we do not use virtual nodes in
> > our Cassandra clusters. Instead, we continue to assign initial_tokens to
> > individual nodes. While we certainly don't expect an operator to support
> > thi

Re: NewBie Question

[Christopher Bradford]

Consider taking a look at Aaron Morton's dive into the C* 3.0 storage
engine.

http://thelastpickle.com/blog/2016/03/04/introductiont-to-the-apache-cassandra-3-storage-engine.html

On Wed, Jun 15, 2016 at 9:38 AM Jim Witschey 
wrote:

> > http://wiki.apache.org/cassandra/ArchitectureSSTable
>
> Be aware that this page hasn't been updated since 2013, so it doesn't
> reflect any changes to the SSTable format since then, including the
> new storage engine introduced in 3.0 (see CASSANDRA-8099).
>
> That said, I believe the linked Apache wiki page is the best
> documentation for the format. Unfortunately, if you want a better or
> more current understanding, you'll have to read the code and read some
> SSTables.
>

Re: Welcome Jeremiah Jordan to the PMC

[Christopher Bradford]

Well done JD!

> On Feb 17, 2025, at 7:08 AM, Piotr Kołaczkowski  wrote:
> 
> Congrats Jeremiah! 
> 
>> Wiadomość napisana przez Berenguer Blasi  w dniu 
>> 17.02.2025, o godz. 07:23:
>> 
>> Congrats JD!! :-)
>> 
>> On 16/2/25 20:52, Bernardo Botella wrote:
>>> Congrats!
>>> 
 El feb 16, 2025, a las 9:08 a. m., Aaron  
  escribió:
 
 Congratulations, JD!
 
 On Sat, Feb 15, 2025 at 7:05 AM Jasonstack Zhao Yang 
 mailto:jasonstack.z...@gmail.com>> wrote:
> Congrats!
> 
> On Sat, 15 Feb 2025 at 20:25, Maxim Muzafarov  > wrote:
>> Congratulation Jeremiah!
>> 
>> On Sat, 15 Feb 2025 at 05:01, Paulo Motta > > wrote:
>> >
>> > Congrats JD!
>> >
>> > On Fri, 14 Feb 2025 at 18:35 guo Maxwell > > > wrote:
>> >>
>> >> Congrats！
>> >> Tolbert, Andy > >> >于2025年2月15日 周六上午6:22写道：
>> >>>
>> >>> Congrats JD!
>> >>>
>> >>> On Fri, Feb 14, 2025 at 4:13 PM > >>> > wrote:
>> 
>>  Congratulations, well deserved!
>> 
>>  El 14 feb 2025, a las 20:40, Alex Petrov >  > escribió:
>> 
>>  
>>  Congratulations!
>> 
>>  On Fri, Feb 14, 2025, at 7:33 PM, Josh McKenzie wrote:
>> 
>>  Congrats Jeremiah!
>> 
>>  I know you're excited to have yet another email list to attend to, 
>>  aren't you? :D
>> 
>>  On Fri, Feb 14, 2025, at 1:29 PM, Jeremiah Jordan wrote:
>> 
>>  Thanks all!  Excited to continue being a part of the project in 
>>  this new role.
>> 
>>  -Jeremiah Jordan
>> 
>>  On Feb 14, 2025 at 12:23:17 PM, Francisco Guerrero 
>>  mailto:fran...@apache.org>> wrote:
>> 
>>  Congrats!
>> 
>>  On 2025/02/14 18:20:02 Yifan Cai wrote:
>> 
>>  Congrats!
>> 
>> 
>>  On Fri, Feb 14, 2025 at 10:16 AM Jordan West >  > wrote:
>> 
>> 
>>  > Congrats, JD! Welcome aboard!
>> 
>>  >
>> 
>>  > Jordan
>> 
>>  >
>> 
>>  > On Fri, Feb 14, 2025 at 11:01 Mick Semb Wever >  > > wrote:
>> 
>>  >
>> 
>>  >>.
>> 
>>  >>
>> 
>>  >> > I hope you will join me in welcoming him to the committee.
>> 
>>  >>
>> 
>>  >>
>> 
>>  >> Welcome JD!
>> 
>>  >>
>> 
>>  >
>> 
>> 
>> 
>> 
>>> 
>