CNDB-8501 Propagate READ_BYTES/WRITE_BYTES sensor via native CQL custom payload #1295

aymkhalil · 2024-09-21T00:06:31Z

Addresses: https://github.com/riptano/cndb/issues/8501
CNDB PR: https://github.com/riptano/cndb/pull/11681

The idea is to expose sensors files to CQL client via the native protocol's custom payload (which is available in V4 or higher). This first iteration add READ_BYTES and WRITE_BYTES.

src/java/org/apache/cassandra/service/StorageProxy.java

src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java

aymkhalil

This ee9566e has the following changes:

Increment sensors for each replica (as opposed to getting sensors value from one and multiplying by replica count). This means we guarantee at least a quorum of replicas sensors rolled up, up to replica count
Add replica responses for writes in memory so later on they can be consulted to rollup sensors values on the REQUEST_RESPONSE stage
Add a RequestSensorsFactory#requestSensorSuffixSupplier to customize sensors prefix in CNDB. Mainly used to append <Keyspace without tenant>.<table name> to WRITE_BYTES_REQUEST header to support batch operations.

… params

…istributed test, and fix ReadExecutorTest

aymkhalil · 2024-10-21T23:48:27Z

src/java/org/apache/cassandra/sensors/RequestSensorsFactory.java

+     *
+     * @return a function that encodes a sensor to a string
+     */
+    default Function<Sensor, String> requestSensorEncoder()


Alternatively, we could combine requestSensorEncoder & registrySensorEncoder into one by either:

Function<Sensor, String> createSensorEncoder(Scope scope) where scope is an Enum of {REQUEST, TABLE}.

Create a separate interface SensorEncoder with an encode method that accepts both Sensor and Scope

Create a separate interface SensorEncoder with an encode method that accepts both Sensor and Scope

I think a dedicated interface would make things clearer, though I would use two different methods rather than an enum?

though I would use two different methods rather than an enum

Makes sense. I think at most we'll have two methods. It is not like it will keep growing with time so an enum (which is basically reduced to a binary check) is not warranted.

sbtourist

First review pass done (no tests).

src/java/org/apache/cassandra/config/CassandraRelevantProperties.java

src/java/org/apache/cassandra/cql3/statements/SelectStatement.java

sbtourist · 2024-10-23T07:01:13Z

src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java

This class doesn't cover batches, is that something you plan to add?

My preference is not to add it in this patch as it is getting bigger in scope. However, this patch should make it easy to add in terms of reusable methods to add sensors & sensor encoder override in CNDB.

I plan to capture all remaining use cases/sensors in one issue after this one is merged.

I'm on the fence here: it's branded as "Propagate READ_BYTES/WRITE_BYTES sensor via native CQL custom payload", and it does that for some statements, but not all.

Do you have any sense of how much bigger would the patch get?

I see what you mean, what I had in mind is other types like Counter Mutation/Index Writer/internode. But should cover the statements that feed into read/write sensors. I'll add them.

src/java/org/apache/cassandra/net/ResponseVerbHandler.java

src/java/org/apache/cassandra/net/SensorsCustomParams.java

sbtourist · 2024-10-23T09:01:22Z

src/java/org/apache/cassandra/service/StorageProxy.java

@@ -1061,6 +1071,12 @@ public static void mutate(List<? extends IMutation> mutations,

        QueryInfoTracker.WriteTracker writeTracker = queryTracker().onWrite(state, false, mutations, consistencyLevel);

+        // Request sensors are utilized to track usages from replicas serving a write request
+        RequestSensors sensors = CassandraRelevantProperties.PROPAGATE_REQUEST_SENSORS_VIA_NATIVE_PROTOCOL.getBoolean() ?


Shouldn't this use RequestSensorsFactory rather than creating things manually? Likewise for reads below.

I thought about this:

Unlike on writers, here what decides if we should track sensors is the REQUEST_SENSORS_VIA_NATIVE_PROTOCOL flag & whether or not sensors values exit in writer response. From this point on, ActiveRequestSensors is the right choice.

a write request at the storage proxy level could contain mutations that belong to different keyspaces. Because we have one RequestSensors per thread, I wasn't sure how to make it per ks. It is worth noting that as far as CNDB is concerned, we enable/disable per tenant (which all keyspaces will belong to a single tenant)

Thoughts?

Also using RequestSensorsFactory would effectively mean (at least in CNDB case) running the logic RequestSensorsFactory#create(keyspace) twice per request - once on the coordinator and another on the writer.

Unlike on writers, here what decides if we should track sensors is the REQUEST_SENSORS_VIA_NATIVE_PROTOCOL flag & whether or not sensors values exit in writer response.

I'm not sure I understand this correctly, but I'd say at this level we should always use RequestSensorsFactory as we're deciding how to track sensors, then we should use REQUEST_SENSORS_VIA_NATIVE_PROTOCOL when deciding if returning them on the native protocol response. Makes sense?

a write request at the storage proxy level could contain mutations that belong to different keyspaces. Because we have one RequestSensors per thread, I wasn't sure how to make it per ks

Good point. This is kind of an anomaly by the API point of view. The instinct says "it's an anomaly, so ignore it and assumes all keyspaces are enabled (or not)", but let me think about that.

I'm not sure I understand this correctly, but I'd say at this level we should always use RequestSensorsFactory as we're deciding how to track sensors, then we should use REQUEST_SENSORS_VIA_NATIVE_PROTOCOL when deciding if returning them on the native protocol response. Makes sense?

I see what you mean. What I'm trying to say is the decision criteria to track sensors on the writer is RequestSensorsFactory but here it is REQUEST_SENSORS_VIA_NATIVE_PROTOCOL. If we disable the latter, there is no point to track sensors on coordinator (at least as far as this patch is concerned). Also, because we have a single RequestSensorsFactory the track/don't track decision will always be the same on writer and coordinators and it sounded redundant to rerun the logic on both components.

Having said that, I don't have a strong opinion here, and the bigger issue is the decision RequestSensorsFactory per ks discussion point so I'll put this on hold until we conclude on the other one.

actually I'm convinced - lets figure out the multiple keyspace things and I'll use RequestSensorsFactory across the board.

Fixed: f9c7af5

src/java/org/apache/cassandra/service/StorageProxy.java

sbtourist · 2024-10-23T09:09:57Z

src/java/org/apache/cassandra/service/StorageProxy.java

CAS, batches and range reads seem not to be covered: is that inteded?

Yes, let us first conclude on the simple read/write case and then I'll create issue/add the rest in a separate patch.

See my other related comment.

Added for CAS: d39b40a

Rest are coming up...

Added for batch: bd952b4

Added for range: dfafba6 (also refactored SensorsTest in a separate commit b9b4f53)

sbtourist · 2024-10-23T09:25:53Z

src/java/org/apache/cassandra/net/ResponseVerbHandler.java

+        if (sensors == null)
+            return;
+
+        if (callbackInfo instanceof RequestCallbacks.WriteCallbackInfo)


Ideally, rather than retrieving the sensors and then populating them here, which requires an instanceof, we should add a populateRequestSensors() method directly to the callback and have specific implementations in there.

That said, AFAIU you've made this because we only have access to the mutation in WriteCallbackInfo, where:

this.mutation = shouldHint(allowHints, message, consistencyLevel) ? message.payload : null;

So the mutation could actually be null.

Two options here:

Make sure the mutation is never null in WriteCallbackInfo.

Rework things so that the mutation can be accessed from the callback.

Thoughts?

AFAIU you've made this because we only have access to the mutation in WriteCallbackInfo

Yes, callbacks (aka. response handlers) are decoupled from the Mutation (after sending Mutation to replicas there is no link back - see where they part ways)

Make sure the mutation is never null in WriteCallbackInfo.

So WriteCallbackInfo extends CallbackInfo - I could store a non-nullable request message payload on the callback info itself which has the following downsides:

WriteCallbackInfo would still have the nullable mutation to avoid changing the shouldHint behavior. Which is a bit weird if the same variable is introduced in parent class.

Would be redundant for ReadCallback as this callback already has the payload (which is ReadCommand). In other words, callbackInfo.payload == callbackInfo.callback.payload for this case.

In any case, we'd still need an instanceof (which btw I agree is underwhelming) to construct a sensors context (Context.from(ReadCommand) vs Context.from(Mutation))

Rework things so that the mutation can be accessed from the callback.

This would be ideal. I tried something like a final instance Mutation variable on AbstractWriteResponseHandler but the issue is we have many different classes implementing AbstractWriteResponseHandler, including in CNDB, and some using composition over inheritance leaving lots of constructors to override. Also a Mutator interface with different implementations to instantiate the callback that we should pass the Mutation to. Perhaps if we end up deciding on this one, I'll do it in separate patch otherwise this one will be more disturbing to review.

Thoughts on the thoughts?

I think you convinced me to give up and leave things as they are :)

…ages)

…roduce getIMutation()

aymkhalil · 2024-11-14T00:43:22Z

src/java/org/apache/cassandra/net/RequestCallbacks.java

@@ -338,7 +342,7 @@ static class WriteCallbackInfo extends CallbackInfo

        public boolean shouldHint()
        {
-            return mutation != null && StorageProxy.shouldHint(replica);
+            return shouldHint && StorageProxy.shouldHint(replica);


This (in addition to `getIMutation on line 362) is the "safest workaround" I could make to carry around a non-nullable Mutation object.

I dunno the history here but I think mutation nullability was dependent on shouldHint is to be memory savvy. For Sensors we need this object at all times. We could add another object or just modify the behavior here to be shouldHint independent. I opted for the latter because judging by tests that failed (on C* & CNDB) majority of use cases use shouldHint so instead of introducing another mutation object for sensors (Which would be redundant most of the time) I thought to decouple mutation nullability from shouldHint

I dunno the history here but I think mutation nullability was dependent on shouldHint is to be memory savvy.

Yep most probably. Looks good.

aymkhalil · 2024-11-14T00:45:28Z

src/java/org/apache/cassandra/net/RequestCallbacks.java

+         * Used for sensors tracking. A safe alternative to {@link #mutation()} to access counter mutations without
+         * changing existing assert behavior.
+         */
+        public IMutation getIMutation()


It looks weird, but the existing mutation() method returns Mutation which is convenient for hints. In order not to changes the assertion behavior and refactoring by returning IMutation - I opted in for a different getter. Note that CounterMutation is IMutation but not Mutation and is needed for sensors (but not hints)

nit: for consistency I'd call this iMutation().

….AbstractSensorsTest: No runnable methods

src/java/org/apache/cassandra/sensors/SensorsFactory.java

sbtourist · 2024-11-26T17:29:45Z

src/java/org/apache/cassandra/sensors/SensorsFactory.java

+    SensorEncoder DEFAULT_SENSOR_ENCODER = new SensorEncoder()
+    {
+        @Override
+        public String encodeRequestSensor(Sensor sensor)


Should we make these two methods return an Optional string, which would be empty by default, so that callers will actually encode and propagate only ifPresent?

Works for me, will apply together with the other comment regarding interface method names

98c0731

although I haven't necessarily used ifPresent because we have typical have another optional for Sensor at encoding time and nested ifPresent deemed less readable. I opted in for early returns. I do see the benefit of not encoding if empty though (better than returning empty strings)

src/java/org/apache/cassandra/service/StorageProxy.java

sbtourist · 2024-11-27T17:58:39Z

test/unit/org/apache/cassandra/sensors/ReplicaSensorsTrackingTest.java

+        assertThat(onResponseStartSignal[replica].await(1, TimeUnit.SECONDS)).isTrue();
+    }
+
+    private void testPrepareCallbackSensorsTracking(Message writeRequest, boolean allowHints) throws InterruptedException


Seems like an odd name?

Yeah I was trying to communicate the fact that the test dimensions are generally the callback type used (rather than the verb or the Message type, with few exceptions :/) because this is how sensors are tracked in ResponseVerbHandler) but a better name is warranted.

sbtourist · 2024-11-27T18:12:42Z

test/unit/org/apache/cassandra/sensors/ReplicaSensorsTrackingTest.java

Several misspellings of actual (i.e. acutal).

sbtourist · 2024-11-27T18:17:05Z

test/distributed/org/apache/cassandra/distributed/test/sensors/SensorsTest.java

+    @Parameterized.Parameters(name = "schema={0}, prepQueries={1}, testQuery={2}, expectedHeaders={3}")
+    public static Collection<Object[]> data()
+    {
+        String tableSchema = withKeyspace("CREATE TABLE %s.tbl (pk int PRIMARY KEY, v1 text)");


These two tables have the same name, is this actually working?

is this actually working?

Yes. If it isn't cassci-bot will report a failure as distributed tests are run in CI. Needless to say it works locally.

All tables are created/destroyed per test permutation, it just happens this one has a different schema.

The reason tables are created in each test permutation is to isolate sensors (won't make much sense for example to read -> assert READ_BYTES -> range read --> assert READ_BYTES unless we opt in for testing exact increments of sensor values which is not really the intent of this test).

sbtourist · 2024-11-27T18:47:19Z

src/java/org/apache/cassandra/cql3/statements/BatchStatement.java

-        return new ResultMessage.Void();
+        ResultMessage<ResultMessage.Void> result = new ResultMessage.Void();
+        RequestSensors sensors = RequestTracker.instance.get();
+        for (ModificationStatement statement : statements)


If all statements refer to the same context, are we then adding the same sensor over and over again?

Great catch. It is suboptimal (but benign, as addSensorToCQLResponse will overwrite the sensor in the header with the same value again and again) - fixed: b752ae8

…OCOL

…ry bytes

aymkhalil

Addressed feedback from 11/27

aymkhalil · 2024-12-02T19:10:44Z

src/java/org/apache/cassandra/config/CassandraRelevantProperties.java

+    /**
+     * If true, the coordinator will propagate request sensors via the native protocol custom payload bytes map.
+     */
+    REQUEST_SENSORS_VIA_NATIVE_PROTOCOL("cassandra.request_sensors_via_native_protocol", "false");


aymkhalil · 2024-12-02T19:25:08Z

test/unit/org/apache/cassandra/sensors/ReplicaSensorsTrackingTest.java

aymkhalil · 2024-12-02T20:04:22Z

src/java/org/apache/cassandra/cql3/statements/BatchStatement.java

-        return new ResultMessage.Void();
+        ResultMessage<ResultMessage.Void> result = new ResultMessage.Void();
+        RequestSensors sensors = RequestTracker.instance.get();
+        for (ModificationStatement statement : statements)


Great catch. It is suboptimal (but benign, as addSensorToCQLResponse will overwrite the sensor in the header with the same value again and again) - fixed: b752ae8

aymkhalil · 2024-12-02T20:07:46Z

src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java

+    {
+        ResultMessage result = super.execute(state, options, queryStartNanoTime);
+
+        if (result == null) result = new ResultMessage.Void();


aymkhalil · 2024-12-02T20:42:18Z

src/java/org/apache/cassandra/db/CounterMutationCallback.java

    }

    private static void addSensorsToResponse(Collection<Sensor> sensors,
-                                             Function<String, String> requestParamSupplier,
-                                             Function<String, String> tableParamSupplier,
                                             Message.Builder<NoPayload> response,
                                             int replicaMultiplier)


+1 118d27c

aymkhalil · 2024-12-02T21:58:50Z

src/java/org/apache/cassandra/sensors/SensorsFactory.java

+
+/**
+ * Provides a factory to customize the behaviour of sensors tracking in CNDB by providing to factory methods:
+ * <li> {@link SensorsFactory#createRequestSensors} provides {@link RequestSensors} implementation to active or deactivate sensors per keyspace</li>


Fixed along side other SensorsFactory java docs comments: 425d27b

aymkhalil · 2024-12-02T22:19:05Z

src/java/org/apache/cassandra/sensors/SensorsCustomParams.java

+
+/**
+ * A utility class that groups methods to facilitate encoding sensors in native or internode protocol messages:
+ * <li>Sensors in internode messages: Use to communicate sensors values from replicas to coordinators in the internode


Fixed along side other java docs comments in SensorsCustomParams be77507

aymkhalil · 2024-12-02T22:27:34Z

test/distributed/org/apache/cassandra/distributed/test/sensors/SensorsTest.java

+    @Parameterized.Parameters(name = "schema={0}, prepQueries={1}, testQuery={2}, expectedHeaders={3}")
+    public static Collection<Object[]> data()
+    {
+        String tableSchema = withKeyspace("CREATE TABLE %s.tbl (pk int PRIMARY KEY, v1 text)");


is this actually working?

Yes. If it isn't cassci-bot will report a failure as distributed tests are run in CI. Needless to say it works locally.

All tables are created/destroyed per test permutation, it just happens this one has a different schema.

The reason tables are created in each test permutation is to isolate sensors (won't make much sense for example to read -> assert READ_BYTES -> range read --> assert READ_BYTES unless we opt in for testing exact increments of sensor values which is not really the intent of this test).

aymkhalil · 2024-12-02T22:30:46Z

test/unit/org/apache/cassandra/sensors/ReplicaSensorsTrackingTest.java

+        assertThat(onResponseStartSignal[replica].await(1, TimeUnit.SECONDS)).isTrue();
+    }
+
+    private void testPrepareCallbackSensorsTracking(Message writeRequest, boolean allowHints) throws InterruptedException


Yeah I was trying to communicate the fact that the test dimensions are generally the callback type used (rather than the verb or the Message type, with few exceptions :/) because this is how sensors are tracked in ResponseVerbHandler) but a better name is warranted.

aymkhalil · 2024-12-02T22:57:59Z

test/unit/org/apache/cassandra/sensors/ReplicaSensorsTrackingTest.java

+        assertThat(onResponseStartSignal[replica].await(1, TimeUnit.SECONDS)).isTrue();
+    }
+
+    private void testPrepareCallbackSensorsTracking(Message writeRequest, boolean allowHints) throws InterruptedException


sonarqubecloud · 2024-12-03T23:43:17Z

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
92.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

cassci-bot · 2024-12-03T23:47:22Z

✔️ Build ds-cassandra-pr-gate/PR-1295 approved by Butler

Approved by Butler
See build details here

aymkhalil commented Sep 21, 2024

View reviewed changes

src/java/org/apache/cassandra/service/StorageProxy.java Outdated Show resolved Hide resolved

aymkhalil commented Sep 21, 2024

View reviewed changes

src/java/org/apache/cassandra/cql3/statements/UpdateStatement.java Outdated Show resolved Hide resolved

CNDB-8501 Propagate request sensors via native CQL custom payload

54b3b28

aymkhalil force-pushed the cndb-8501 branch from 114f9ea to 54b3b28 Compare September 21, 2024 00:16

aymkhalil requested a review from sbtourist September 21, 2024 04:17

aymkhalil changed the title ~~CNDB-8501 Propagate sensors vials via native CQL custom payload~~ CNDB-8501 Propagate sensors via native CQL custom payload Sep 24, 2024

aymkhalil requested a review from maxtomassi October 1, 2024 23:19

Propagate READ_BYTES only

7613307

aymkhalil marked this pull request as ready for review October 2, 2024 05:34

aymkhalil changed the title ~~CNDB-8501 Propagate sensors via native CQL custom payload~~ CNDB-8501 Propagate READ_BYTES sensor via native CQL custom payload Oct 2, 2024

aymkhalil added 2 commits October 8, 2024 09:12

Merge branch 'main' into cndb-8501

c755d86

Add WRITE_BYTES and customize header prefix

ee9566e

aymkhalil commented Oct 15, 2024

View reviewed changes

Fix typo

8bf72a9

aymkhalil changed the title ~~CNDB-8501 Propagate READ_BYTES sensor via native CQL custom payload~~ CNDB-8501 Propagate READ_BYTES/WRITE_BYTES sensor via native CQL custom payload Oct 15, 2024

aymkhalil added 6 commits October 15, 2024 15:14

Fix CounterMutationCallbackTest

1e3092a

Track replica sensors in ResponseVerbHandler + refactor custom sensor…

55454d9

… params

Add ReplicaSensorsTrackedTest unit tests, more tests in SensorsTest d…

f8a1fc6

…istributed test, and fix ReadExecutorTest

Fix CounterMutationCallbackTest

7c19ca5

Cleanup

2373ede

Remove unnecessary instanceof check

1311836

aymkhalil force-pushed the cndb-8501 branch from 751df24 to 1311836 Compare October 21, 2024 22:11

SensorEncoder java docs

78ef0b5

aymkhalil commented Oct 21, 2024

View reviewed changes

sbtourist reviewed Oct 23, 2024

View reviewed changes

aymkhalil added 5 commits October 23, 2024 13:51

Address generic feedback (javadocs, code style, leftovers, class pack…

42a41f2

…ages)

Add SensorEncoder interface

31dfa8f

table -> global everywhere

fe0628b

Register sensors before the mutate call

7a9c72f

Add to instead of replacing custom payload

42b8ebf

Decouple WriteCallbackInfo#shouldHint from mutation nullability & int…

833fd89

…roduce getIMutation()

aymkhalil force-pushed the cndb-8501 branch from 85bd6cb to 833fd89 Compare November 13, 2024 22:42

erge branch 'main' into cndb-8501

0b74852

aymkhalil commented Nov 14, 2024

View reviewed changes

aymkhalil added 3 commits November 13, 2024 17:25

Add Counter mutation dtest

6287335

Fix Invalid test class 'org.apache.cassandra.distributed.test.sensors…

d4a3d6e

….AbstractSensorsTest: No runnable methods

Squash AbstractSensorsTest & SensorsTest into one class

35ba7ce

sbtourist reviewed Nov 27, 2024

View reviewed changes

Rename REQUEST_SENSORS_VIA_NATIVE_PROTOCOL -> REQUEST_VIA_NATIVE_PROT…

bc11b24

…OCOL

aymkhalil force-pushed the cndb-8501 branch from 8dacce1 to bc11b24 Compare December 2, 2024 19:16

aymkhalil added 12 commits December 2, 2024 11:24

Fix typos acutal -> actual

0bc81cd

Collect unique contexts from batch statements for adding sensors

b752ae8

Don't inline if for readability

e082a6f

Reuse addSensorsToInternodeResponse in CounterMutationCallback

118d27c

Refactor RequestCallbacks#getIMutaiton to iMutation()

d9d70c0

Fix ActiveSensorsFactory javadocs

e4e18fc

Switch from ByteBuffer.allocate to ByteBuffer.wrap to spare some memo…

a77b5e6

…ry bytes

Fix SensorsFactory javadocs

425d27b

Fix SensorsCustomParams javadocs

be77507

Remove leading li tag spaces in SensorsFactory

b4b0076

Remove extra colon in StorageProxy

6682ba8

Better methods names in ReplicaSensorsTrackingTest

670f755

aymkhalil force-pushed the cndb-8501 branch from f5283a4 to 670f755 Compare December 2, 2024 22:56

Merge branch 'main' into cndb-8501

795d089

aymkhalil commented Dec 2, 2024

View reviewed changes

Refactor SensorEncoder methods to return optional & have better names

98c0731

jkni self-requested a review December 18, 2024 22:08

CNDB-8501 Propagate READ_BYTES/WRITE_BYTES sensor via native CQL custom payload #1295

Are you sure you want to change the base?

CNDB-8501 Propagate READ_BYTES/WRITE_BYTES sensor via native CQL custom payload #1295

Conversation

aymkhalil commented Sep 21, 2024 • edited by sbtourist Loading

aymkhalil left a comment

Choose a reason for hiding this comment

aymkhalil Oct 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbtourist left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sbtourist Nov 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aymkhalil Nov 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aymkhalil left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sonarqubecloud bot commented Dec 3, 2024

Quality Gate passed

cassci-bot commented Dec 3, 2024

✔️ Build ds-cassandra-pr-gate/PR-1295 approved by Butler

aymkhalil commented Sep 21, 2024 •

edited by sbtourist

Loading

aymkhalil Oct 21, 2024 •

edited

Loading

sbtourist Nov 5, 2024 •

edited

Loading

aymkhalil Nov 7, 2024 •

edited

Loading