Support PaaS Cassandra - Create Schema on Azure CosmosDB

[MarianZoll]

Requirement - what kind of business use case are you trying to solve?

Connect to an Azure Cosmos DB managed Cassandra-API to reduce the operational overhead on the databases.

Additional context is available here #2467

Problem - what in Jaeger blocks you from solving the requirement?

• Cassandra API does not support frozen collection types at the moment: https://docs.microsoft.com/en-us/azure/cosmos-db/cassandra-secondary-index
• CQL definition language needs to be adjusted.

Proposal - what do you suggest to solve the problem or improve the existing situation?

• Remove frozen definitions
• Adjust the definition language; for what I tested so far its mostly removing the last , in the definition language.

https://github.com/jaegertracing/jaeger/blob/master/plugin/storage/cassandra/schema/v003.cql.tmpl#L35-L38

Any open questions to address

Maybe we can start to discuss the approach.

[jpkrohling]

This is only about the create schema job, right? I think we could provide a second set of files, for Azure's CosmosDB.

[MarianZoll]

Correct, its just about the create schema job. I would do a first check whether it is really just the two things by applying the CQL. Maybe its easier to just use a sed or something to remove the frozens but keep the same set of files due to maintenance ease. I'll do a quick check and describe the findings here so that we can decide what the easiest way would be. What do you think?

[jpkrohling]

If you can do it with a couple of sed commands, I'd be all for it. We just need to build safe guards, so that those still work in the future and that we'll get a notification in case it breaks. For instance, it should be part of the build process.

[sshah90]

Hi, do we have any update on this?

We are planning to deploy Jaeger into our Azure stack but we don't have expertise in Cassandra.

[MarianZoll]

@sshah90 I did not had time to proceed with the implementation, so feel free to take over.

[sshah90]

I made changes as mentioned here in my customize local jaeger-cassandra-schema image, but still getting the following error when I run the image.

Attaching to jaeger-cassandra_app_1
app_1  | 
app_1  | system_schema  system              system_traces
app_1  | system_auth    system_distributed  jaeger_index 
app_1  | 
app_1  | Generating the schema for the keyspace jaeger_index and datacenter dc1
app_1  | Using template file /cassandra-schema/v003.cql.tmpl with parameters:
app_1  |     mode = test
app_1  |     datacenter = dc1
app_1  |     keyspace = jaeger_index
app_1  |     replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}
app_1  |     trace_ttl = 172800
app_1  |     dependencies_ttl = 0
app_1  | <stdin>:13:SyntaxException: line 1:39 no viable alternative at input 'keyvalue (...IF NOT EXISTS jaeger_index.keyvalue...)
app_1  | <stdin>:18:SyntaxException: line 3:110 no viable alternative at input 'keyvalue (...g (
app_1  |     ts      bigint, // microseconds since epoch
app_1  |     fields  list<keyvalue...)
app_1  | <stdin>:29:SyntaxException: line 3:100 no viable alternative at input 'keyvalue (...(
app_1  |     service_name    text,
app_1  |     tags            list<keyvalue...)
app_1  | <stdin>:54:SyntaxException: line 10:335 no viable alternative at input 'keyvalue (...  operation_name  text,
app_1  |     flags           int,
app_1  |     start_time      bigint, // microseconds since epoch
app_1  |     duration        bigint, // microseconds
app_1  |     tags            list<keyvalue...)
jaeger-cassandra_app_1 exited with code 2

Any Suggestions?

[adamlepkowski]

Did someone manage to run it?

[yurishkuro]

CosmosDB explicitly states that frozen collections are not supported - the key is not just "frozen", but the fact that they are collections. Jaeger uses manual indexing of data in Cassandra, so secondary indexing of Cosmos is not necessary, and if we did want to support db-native indexing I think we'd need to seriously rethink the whole implementation. Closing this as wontfix.