You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Requirement - what kind of business use case are you trying to solve?
Connect to a cloud-provider managed Cassandra to reduce the operational overhead on the databases. Unfortunately, for most cloud providers, a non 9042 port is used and SSL is required.
We are running CosmosDB with the Cassandra API, so this is another thing we might want to address. According to a couple of issues this might be reasonable to support: #1105 #1667 apache/cassandra-gocql-driver#1205
Problem - what in Jaeger blocks you from solving the requirement?
Cassandra create schema does not support other ports than the default 9042 for the CQL connection.
Currently, the environment variable can be set using manual env injection as described here: #2366. Unfortunately, this is not considered by the create schema as it is a separate container.
Proposal - what do you suggest to solve the problem or improve the existing situation?
For operator based installations I already addressed the topic in jaegertracing/jaeger-operator#1179 and we narrowed down some aspects to consider.
To create the Cassandra schema, we have to change the following to support environment variables like CQLSH_PORT.
I'd also like to work on the Azure Cosmos DB schema creation. The issues mentioned (especially: #1105) pretty much already point out what needs to be done and for me it looks like this might be possible without creating a new backend provider as discussed in other threads. The biggest blocker is most probably the frozen annotations.
To configure SSL certificates, I would suggest to have an option to use your own set of certs or support some "well-known" CAs like Lets Encrypt. I know about https://www.jaegertracing.io/docs/1.18/deployment/#tls-support but providing additional files is not that nice for K8s based deployments when it comes to developer experience and co.
Any open questions to address
Maybe we can start to discuss the approach.
The text was updated successfully, but these errors were encountered:
Could you break this down in individual tasks? One for adding the port to the create-schema script/image, one for the changes to get the create schema to work on Azure, and one for the TLS certs. The first is a must-have, in my opinion, the second might not be problematic too, but not sure I agree with the third.
Requirement - what kind of business use case are you trying to solve?
Connect to a cloud-provider managed Cassandra to reduce the operational overhead on the databases. Unfortunately, for most cloud providers, a non 9042 port is used and SSL is required.
We are running CosmosDB with the Cassandra API, so this is another thing we might want to address. According to a couple of issues this might be reasonable to support:
#1105
#1667
apache/cassandra-gocql-driver#1205
Problem - what in Jaeger blocks you from solving the requirement?
Currently, the environment variable can be set using manual env injection as described here: #2366. Unfortunately, this is not considered by the create schema as it is a separate container.
Proposal - what do you suggest to solve the problem or improve the existing situation?
For operator based installations I already addressed the topic in jaegertracing/jaeger-operator#1179 and we narrowed down some aspects to consider.
To create the Cassandra schema, we have to change the following to support environment variables like
CQLSH_PORT
.jaeger/plugin/storage/cassandra/schema/docker.sh
Lines 6 to 15 in 043d00c
I'd also like to work on the Azure Cosmos DB schema creation. The issues mentioned (especially: #1105) pretty much already point out what needs to be done and for me it looks like this might be possible without creating a new backend provider as discussed in other threads. The biggest blocker is most probably the frozen annotations.
To configure SSL certificates, I would suggest to have an option to use your own set of certs or support some "well-known" CAs like Lets Encrypt. I know about https://www.jaegertracing.io/docs/1.18/deployment/#tls-support but providing additional files is not that nice for K8s based deployments when it comes to developer experience and co.
Any open questions to address
Maybe we can start to discuss the approach.
The text was updated successfully, but these errors were encountered: