I think in the context of what I think initially motivated this hot
reloading capability, a big win it provides is avoiding having to
bounce your cluster as your certificates near expiry. If not watched
closely you can get yourself into a state where every node in the
cluster's cert expired,
I think it's all part of the same issue and you're not derailing IMO Abe. For
the user Pabbireddy here, the unexpected behavior was not closing internode
connections on that keystore refresh. So ISTM, from a "featureset that would be
nice to have here" perspective, we could theoretically
Not to derail from the original conversation too far, but wanted to agree that
maximum connection establishment time on native transport would be useful. That
would provide a maximum duration before an updated client keystore is used for
connections, which can be used to safely roll out client
It seems like if folks really want the life of a connection to be finite
(either client/server or server/server), adding in an option to quietly drain
and recycle a connection on some period isn’t that difficult.
That type of requirement shows up in a number of environments, usually on
In addition to what Andy mentioned, I want to point out that for the vast
majority of use-cases, we would like to _avoid_ interruptions when a
certificate is updated so it is by design. If you're dealing with a
situation where you want to ensure that the connections are cycled, you can
follow
I should mention, when toggling disablebinary/enablebinary between
instances, you will probably want to give some time between doing this
so connections can reestablish, and you will want to verify that the
connections can actually reestablish. You also need to be mindful of
this being disruptive
Thanks Andy for your reply . We will test the scenario you mentioned.
Regards
Avinash
On Mon, Apr 15, 2024 at 11:28 AM, Tolbert, Andy wrote:
> Hi Avinash,
>
> As far as I understand it, if the underlying keystore/trustore(s)
> Cassandra is configured for is updated, this *will not* provoke
>
Hi Avinash,
As far as I understand it, if the underlying keystore/trustore(s)
Cassandra is configured for is updated, this *will not* provoke
Cassandra to interrupt existing connections, it's just that the new
stores will be used for future TLS initialization.
Via:
Dear Community,
I hope this email finds you well. I am currently testing SSL certificate
hot reloading on a Cassandra cluster running version 4.1 and encountered a
situation that requires your expertise.
Here's a summary of the process and issue:
1.
Reloading Process: We reloaded
