Bigtable Support

[olivierboucher]

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

Implementing a new storage backend for GCP's Bigtable

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

Probably issue #422

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

Implementing and maintaining the new backend plugin

Any open questions to address

Does it have any chance to be merged? Is #422 preventing any backend from being added?

This issue could be added to #638

[yurishkuro]

Hi @olivierboucher

Does it have any chance to be merged?

The maintainers have limited resources to maintain and enhance storage implementations, so our strategy is to stick with the two supported open source solutions (Elasticsearch and Casandra), and enable other implementations to be done as community-supported plugins. We would be fine to host those plugins under the jaegertracing org, e.g. jaegertracing/storage-bigtable repository, where the original implementors will have maintainer rights.

Is #422 preventing any backend from being added?

Unfortunately, yes, we have been short-handed to move on that issue, even though the amount of work is not large, if we use the harshicorp plugin & the new protobuf model. If you would like to contribute the basic plugin framework for storage, it will enable all those listed in #638 to proceed. I am happy to provide guidance & reviews about that.

[olivierboucher]

Hi @yurishkuro

This sounds like an interesting project. Should PRs be based from master?

[yurishkuro]

Yes, we base everything off master. If you're interested, I would recommend building a prototype with harshicorp plugin and the existing in-memory storage, just to demonstrate the plumbing (and maybe some comparative perf tests of IPC-based plugin vs. in-process plugin).

[mandarjog]

@douglas-reid an interesting project for istio perhaps?

[yurishkuro]

There has been no activity here, I assume there is not enough interest, so closing as wontfix.