I think I made a small mistake in the design of the v2 storage configuration. The jaeger_storage extension defines configurations for all storage backends, but does not actually takes a position which ones are which. This leads to two problems:
The other components need to make this choice and be in sync. Specifically jaeger_storage_exporter and jaeger_query both require TraceStorage name which they use to retrieve a storage factory from jaeger_storage
The primary/archive storage distinction work #6156 revealed that storage factory needs the is_archive input parameter to customize the backend implementation specifically for archive storage needs. However, in the current setup jaeger_storage does not know this distinction, so in #6156 a new config flag is being proposed, which is technically redundant.
Proposal
Move selection of specific storage implementations into jaeger_storage extension as well. Right now the config might look like:
And we would remove the corresponding entries from jaeger_query and exporter. Currently query/exporter use the GetFactory(name) function from the extension, instead they would be asking for specific role like GetTracesStorageFactory, GetTraceArchiveStorageFactory, etc.
Benefits:
query/exporter do not need to be in sync on the name of the storage backend
jaeger_storage will know to which role a particular backend is assigned, so when instantiating a factory it can pass additional flags like is_archive as needed
I think I made a small mistake in the design of the v2 storage configuration. The
jaeger_storage
extension defines configurations for all storage backends, but does not actually takes a position which ones are which. This leads to two problems:jaeger_storage_exporter
andjaeger_query
both requireTraceStorage
name which they use to retrieve a storage factory fromjaeger_storage
is_archive
input parameter to customize the backend implementation specifically for archive storage needs. However, in the current setupjaeger_storage
does not know this distinction, so in #6156 a new config flag is being proposed, which is technically redundant.Proposal
Move selection of specific storage implementations into
jaeger_storage
extension as well. Right now the config might look like:We can add a new section that would explicitly assign the roles to different backends:
And we would remove the corresponding entries from
jaeger_query
and exporter. Currently query/exporter use the GetFactory(name) function from the extension, instead they would be asking for specific role likeGetTracesStorageFactory
,GetTraceArchiveStorageFactory
, etc.Benefits:
jaeger_storage
will know to which role a particular backend is assigned, so when instantiating a factory it can pass additional flags likeis_archive
as needed