[storage] Remove dependency on archive flag in ES reader #6490

mahadzaryab1 · 2025-01-06T00:55:52Z

Which problem is this PR solving?

Towards Phase out the distinction between primary and archive storage #6065

Description of the changes

This PR removes the concept of archive from the ElasticSearch span reader and span writer by relying on the following configurations:
- The index names in the archive storage are a special case of the use_aliases configuration so the archive bool in the archive reader was mostly replaced by the use_aliases configuration (more details on this are in the description of Phase out the distinction between primary and archive storage #6065).
- To maintain backwards compatibility, we had to move some of the construction of the aliases to CreateArchiveSpanReader and CreateArchiveSpanWriter

How was this change tested?

CI

Checklist

I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md
I have signed all commits
I have added unit tests for the new functionality
I have run lint and test steps successfully
- for jaeger: make lint test
- for jaeger-ui: npm run lint and npm run test

mahadzaryab1 · 2025-01-06T00:56:18Z

plugin/storage/es/spanstore/reader.go

@@ -124,6 +123,7 @@ func NewSpanReader(p SpanReaderParams) *SpanReader {
 	if p.UseReadWriteAliases {
 		maxSpanAge = rolloverMaxSpanAge
 	}
+	archive := maxSpanAge == 0


@yurishkuro do we want to remove the concept of archive altogether? should we call this variable something else?

yes, in the reader / writer (only leave it in Factory for now)

mahadzaryab1 · 2025-01-06T00:58:46Z

@yurishkuro How should we handle the archive namespacing in the reader and factory as they are currently hardcoded.

plugin/storage/es/factory.go

plugin/storage/es/spanstore/reader.go

codecov · 2025-01-06T22:41:34Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.25%. Comparing base (97a9f06) to head (b785631).

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #6490       +/-   ##
===========================================
+ Coverage   50.22%   96.25%   +46.03%     
===========================================
  Files         188      372      +184     
  Lines       11403    21283     +9880     
===========================================
+ Hits         5727    20486    +14759     
+ Misses       5218      609     -4609     
+ Partials      458      188      -270

Flag	Coverage Δ
badger_v1	`10.67% <0.00%> (-0.01%)`	⬇️
badger_v2	`2.78% <0.00%> (-0.01%)`	⬇️
cassandra-4.x-v1-manual	`16.57% <0.00%> (-0.01%)`	⬇️
cassandra-4.x-v2-auto	`2.71% <0.00%> (-0.01%)`	⬇️
cassandra-4.x-v2-manual	`2.71% <0.00%> (-0.01%)`	⬇️
cassandra-5.x-v1-manual	`16.57% <0.00%> (-0.01%)`	⬇️
cassandra-5.x-v2-auto	`2.71% <0.00%> (-0.01%)`	⬇️
cassandra-5.x-v2-manual	`2.71% <0.00%> (-0.01%)`	⬇️
elasticsearch-6.x-v1	`20.36% <75.51%> (+0.11%)`	⬆️
elasticsearch-7.x-v1	`20.44% <75.51%> (+0.11%)`	⬆️
elasticsearch-8.x-v1	`20.60% <75.51%> (+0.10%)`	⬆️
elasticsearch-8.x-v2	`2.78% <0.00%> (-0.01%)`	⬇️
grpc_v1	`12.20% <0.00%> (-0.01%)`	⬇️
grpc_v2	`9.03% <0.00%> (-0.02%)`	⬇️
kafka-3.x-v1	`10.36% <0.00%> (-0.01%)`	⬇️
kafka-3.x-v2	`2.78% <0.00%> (-0.01%)`	⬇️
memory_v2	`2.77% <0.00%> (-0.01%)`	⬇️
opensearch-1.x-v1	`20.48% <75.51%> (+0.09%)`	⬆️
opensearch-2.x-v1	`20.49% <75.51%> (+0.11%)`	⬆️
opensearch-2.x-v2	`2.77% <0.00%> (-0.01%)`	⬇️
tailsampling-processor	`0.51% <0.00%> (-0.01%)`	⬇️
unittests	`95.13% <100.00%> (?)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

plugin/storage/es/spanstore/reader.go

mahadzaryab1 · 2025-01-08T00:42:45Z

plugin/storage/es/factory.go

@@ -218,7 +218,8 @@ func (f *Factory) CreateArchiveSpanReader() (spanstore.Reader, error) {
 	if !f.archiveConfig.Enabled {
 		return nil, nil
 	}
-	sr, err := createSpanReader(f.getArchiveClient, f.archiveConfig, true, f.logger, f.tracer)
+	// TODO: should use_aliases be always set to true here?


@yurishkuro thoughts on this? is it okay to just respect the user input here?

no, I think you need to override use_aliases=true here, because it may not be set via CLI flags. jaeger-v2 won't go through this code path at all, so for v2 user input would be respected.

yurishkuro · 2025-01-08T02:59:13Z

plugin/storage/es/spanstore/writer.go

-	if p.Archive {
-		return func(_ time.Time) (string, string) {
-			if p.UseReadWriteAliases {
-				return archiveIndex(spanIndexPrefix, archiveWriteIndexSuffix), ""


need to test that it would still go to the same index names by default (may need to set some params in CreateAechiveWriter

plugin/storage/es/spanstore/writer_test.go

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 · 2025-01-08T23:20:28Z

plugin/storage/es/factory.go

+	suffix := "archive"
+	if f.archiveConfig.UseReadWriteAliases {
+		suffix += "-read"
+	}
+	sr, err := createSpanReader(f.getArchiveClient, f.archiveConfig, f.logger, f.tracer, suffix, true)


@yurishkuro Not ideal to have to do this but this is roughly what we need to maintain backwards compatibility.

I'm not sure if we want to expose a configuration option to override the default read and write alias but that could be one way to streamline this.

who adds read/write suffix to the index name?

how does that work for non-archive, does it not use -read suffix?

who adds read/write suffix to the index name?

Its added by the reader and the writer but we need to handle the special case where the archive storage also has use_aliases set to true

how does that work for non-archive, does it not use -read suffix?

Yeah it does - its done by the reader and the writer. I made some changes to make it an else-if change. The current behavior is that if a suffix is passed in, we use that. If a suffix isn't passed in but use_aliases is set, then we use the default read/write aliases.

that's why I don't follow - if reader/writer automatically add -read/-write suffix, why do you need to add it manually above?

I add it above just to address the case where use_aliases wasn't initially set for the archive storage. Since we hardcode it to true for the archive storage now, we'll always set the index to be archive-read and archive-write in the reader/writer. But that would break backwards compatibility because previously it would just be archive for both the read and write alias for the archive storage.

Signed-off-by: Mahad Zaryab <[email protected]>

yurishkuro · 2025-01-10T02:51:35Z

plugin/storage/es/spanstore/reader.go

 	return func(query elastic.Query, nextTime uint64) *elastic.SearchSource {
 		s := elastic.NewSearchSource().
 			Query(query).
 			Size(maxDocCount)
-		if !archive {
+		if !useReadWriteAliases {


this looks a bit suspicious. If you have a query that specifies the time range, e.g. (t-1d, t), and the index rotation frequency is 1 day with 7 days retention, then the read alias will cover all 7 days. It's more efficient to give the time range to the query because it could (theoretically) perform filtering of the indices based on the time range first and not search all 7 of them.

So question: do we have to exclude these two clauses? What's the upstream call path to this function, does it include both FindTraces and GetTrace? Where does the GetTrace get the time frame (since we didn't have it as part of GetTrace API until very recently)?

Was just reading about ES aliases and I may be wrong, it doesn't look like it actually optimizes which indices to search. But since each index will have an inverted index no the time, ES would be able to quickly discard those indices if the query itself contains a date_range. So my question still stands - should we be really dropping the nextTime filter?

@yurishkuro Here is where the GetTrace function gets the time frame. It subtracts the max span age from the current time to get the start time and then use the current time as the end time (and then looks in 1 hour past in each direction)

I pushed up a change that keeps the filter to see how the CI reacts. I think I tried this before and the integration tests complained but that may have been due to a different reason.

@yurishkuro It looks good!

mahadzaryab1 · 2025-01-10T03:34:00Z

plugin/storage/es/factory.go

+	if f.archiveConfig.UseReadWriteAliases {
+		writeAlias += "-write"
+	}
+	return createSpanWriter(f.getArchiveClient, f.archiveConfig, f.archiveMetricsFactory, f.logger, writeAlias, true)


@yurishkuro With the latest change, we may actually not even need to hardcode use_aliases to true anymore since the only differentiator that remains is the actual alias that is used. If we want, we can change the ES reader to just take an optional suffix and then do something like this in getTimeRangeIndexFn where suffix directly replaces the archive bool

if (suffix != "") { if (use_aliases) { return suffix + read } return suffix } if (use_aliases) { return read } return time ranged indices

Do you have a preference between the approach we currently have or the one that I just described?

yurishkuro · 2025-01-11T17:03:24Z

plugin/storage/es/spanstore/reader.go

-		var archiveSuffix string
+func getTimeRangeIndexFn(readAlias string, useReadWriteAliases bool, remoteReadClusters []string) timeRangeIndexFn {
+	if readAlias != "" {
+		var suffix string


can simplify

suffix := readAlias if useReadWriteAliases { suffix += "-read" }

yurishkuro · 2025-01-11T17:07:19Z

plugin/storage/es/spanstore/writer.go

 			}
-			return archiveIndex(spanIndexPrefix, archiveIndexSuffix), ""


I guess in the archive mode we never needed to write into service index since archive storage is only used to retrieve traces by ID, not to do any searches. Not sure if we can infer the same from some other signal / parameter.

yurishkuro · 2025-01-11T17:09:49Z

plugin/storage/es/factory.go

@@ -218,7 +218,7 @@ func (f *Factory) CreateArchiveSpanReader() (spanstore.Reader, error) {
 	if !f.archiveConfig.Enabled {
 		return nil, nil
 	}
-	sr, err := createSpanReader(f.getArchiveClient, f.archiveConfig, true, f.logger, f.tracer)
+	sr, err := createSpanReader(f.getArchiveClient, f.archiveConfig, f.logger, f.tracer, "archive")


I think we need to make this new parameter part of the config and pass it that way, otherwise how would v2 be able to do it since we don't want it to call CreateArchiveSpanReader in the future

@yurishkuro +1 - would you prefer it done in this PR? I was initially going to create a follow-up for it

mahadzaryab1 · 2025-01-11T21:11:31Z

@yurishkuro A bit of a summary on how things are working in v1 today:

For the archive reader, there can be two suffixes for the alias today:

archive - if use_aliases is false
archive-read- if use_aliases is true

Likewise, for archive-writer,

archive - if use_aliases is false
archive-read - if use_aliases is true

This PR makes a change to remove the if archive check and have the reader take in a ReadAlias and the writer take in a WriteAlias. If we wanted the same behaviour to be accessible via v2, then we would need to expose the following configuration

use_aliases: // already exposed
read_alias: 
write_alias:

However, this shouldn't be necessary because if each storage has a unique indexPrefix, then needing another alias shouldn't be required. So, let's assume we decide not to expose the read_alias and write_alias to users. In that case, the only difference would be is that the if condition below would always be set to true, which I think we discussed before and is acceptable.

func getSourceFn(readAlias string, maxDocCount int) sourceFn {
	return func(query elastic.Query, nextTime uint64) *elastic.SearchSource {
		s := elastic.NewSearchSource().
			Query(query).
			Size(maxDocCount)
		if readAlias == "" {
			s.Sort("startTime", true).
				SearchAfter(nextTime)
		}
		return s
	}
}

Consider the following block in the multiRead function. A different query is used when useReadWriteAliases is true. I think if we change the if condition to be if s.useReadWriteAliases || s.readAlias != "", then we should we able to remove the indirection from getSourceFn and now the equivalent behaviour can be achieved in v2 by simply using the use_aliases flag and not needing to expose the read_alias and write_alias flag at all. EDIT: I tried this and it didn't work. This is because the span in the ArchiveTrace integration test is 5 days old which it can't find if we remove the check from getSourceFn.

			if s.useReadWriteAliases {
				startTimeRangeQuery := s.buildStartTimeQuery(startTime.Add(-time.Hour*24), endTime.Add(time.Hour*24))
				query = query.Must(startTimeRangeQuery)
			}

			if val, ok := searchAfterTime[traceID]; ok {
				nextTime = val
			}

			s := s.sourceFn(query, nextTime)

One other solution that we could think about is changing the if readAlias == "" check in getSourceFn to be if readAlias == "" || !useReadWriteAliases

yurishkuro · 2025-01-11T21:46:54Z

This condition

		if readAlias == "" {
			s.Sort("startTime", true).
				SearchAfter(nextTime)
		}

looks very fishy to me. It's not whether we actually use aliases (the boolean), but it's checking if the suffix of the alias is blank - that kind of difference cannot be driving different behavior of the search. 3 months later I would never be able to explain why this is happening based on readAlias == "".

Your analysis is incomplete, so it makes it difficult to understand. It's not just the suffixes that are changing, the way indices are organized is also changing, so the logic should be based on the latter, not on the index naming. Why is it that Sort/SearchAfter need to be skipped in some cases?

mahadzaryab1 · 2025-01-11T22:14:55Z

This condition
		if readAlias == "" {
			s.Sort("startTime", true).
				SearchAfter(nextTime)
		}
looks very fishy to me. It's not whether we actually use aliases (the boolean), but it's checking if the suffix of the alias is blank - that kind of difference cannot be driving different behavior of the search. 3 months later I would never be able to explain why this is happening based on readAlias == "".

Your analysis is incomplete, so it makes it difficult to understand. It's not just the suffixes that are changing, the way indices are organized is also changing, so the logic should be based on the latter, not on the index naming. Why is it that Sort/SearchAfter need to be skipped in some cases?

@yurishkuro The test span in the ArchiveTrace integration test is 360 hours old. But the maxSpanAge is 72 hours. Consider the following block from GetTrace

func (s *SpanReader) GetTrace(ctx context.Context, query spanstore.GetTraceParameters) (*model.Trace, error) {
	ctx, span := s.tracer.Start(ctx, "GetTrace")
	defer span.End()
	currentTime := time.Now()
	// TODO: use start time & end time in "query" struct
	traces, err := s.multiRead(ctx, []model.TraceID{query.TraceID}, currentTime.Add(-s.maxSpanAge), currentTime)

The startTime is set to 72 hours in the past. If we look inside multiRead, we have

nextTime := model.TimeAsEpochMicroseconds(startTime.Add(-time.Hour))

which is used in

s := s.sourceFn(query, nextTime)

The distinction is needed because without it, we would only query data that is newer than 73 hours in the case of the integration test, but we don't want that limit when looking for traces in the archive storage. Should we introduce a new configuration that does that?

yurishkuro · 2025-01-11T22:21:48Z

good find, so this is what I meant by repurposing maxSpanAge - if it' set large enough for the archive storage (to reflect the actual retention), does this this bifurcation goes away?

mahadzaryab1 · 2025-01-11T22:24:39Z

good find, so this is what I meant by repurposing maxSpanAge - if it' set large enough for the archive storage (to reflect the actual retention), does this this bifurcation goes away?

Yeah - in that case it should. We could try it out by changing the startTime in the integration test to be within the maxSpanAge. Although, this would result in a breaking change, right?

yurishkuro · 2025-01-11T22:50:25Z

What specifically would be the breaking change? From your explanation it sounds like maxSpanAge is not used for archive queries to day at all, so in create-archive we can set it to a large number like 10yrs, this will be backwards compatible.

mahadzaryab1 · 2025-01-11T22:57:34Z

What specifically would be the breaking change? From your explanation it sounds like maxSpanAge is not used for archive queries to day at all, so in create-archive we can set it to a large number like 10yrs, this will be backwards compatible.

Ah okay got it - makes sense. It looks like we already do this for use_aliases

	maxSpanAge := p.MaxSpanAge
	// Setting the maxSpanAge to a large duration will ensure all spans in the "read" alias are accessible by queries (query window = [now - maxSpanAge, now]).
	// When read/write aliases are enabled, which are required for index rollovers, only the "read" alias is queried and therefore should not affect performance.
	if p.UseReadWriteAliases {
		maxSpanAge = rolloverMaxSpanAge
	}

It would be nice to leverage that flag but doesn't work because of the archive/archive-read indices that we need to keep for backwards compatibility. We could revisit the old approach if we'd like of checking for use_aliases in CreateArchiveSpanReader - what do you think?

yurishkuro · 2025-01-11T23:02:50Z

doesn't work because of the archive/archive-read indices that we need to keep for backwards compatibility

what specifically is the issue?

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 · 2025-01-11T23:09:09Z

doesn't work because of the archive/archive-read indices that we need to keep for backwards compatibility

what specifically is the issue?

@yurishkuro We need to be able to respect the case where archive storage has use_aliases set to either true or false. It should be good now - I just handle that case in CreateArchiveSpanReader. We shouldn't need to expose any new configs for v2 with the current setup. Albeit, I think this might be a breaking change once we switch the query extension to use the primary api for archive storage as well because the -archive index won't be used by default anymore.

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 · 2025-01-11T23:13:28Z

doesn't work because of the archive/archive-read indices that we need to keep for backwards compatibility

what specifically is the issue?

@yurishkuro We need to be able to respect the case where archive storage has use_aliases set to either true or false. It should be good now - I just handle that case in CreateArchiveSpanReader. We shouldn't need to expose any new configs for v2 with the current setup. Albeit, I think this might be a breaking change once we switch the query extension to use the primary api for archive storage as well because the -archive index won't be used by default anymore.

Oh - just saw #6519 (review). Looks like we're on the same page then.

yurishkuro

I think this is in good shape, with some minor tweaks for readability.

yurishkuro · 2025-01-12T02:51:28Z

plugin/storage/es/spanstore/reader.go

@@ -136,9 +139,9 @@ func NewSpanReader(p SpanReaderParams) *SpanReader {
 		spanConverter:           dbmodel.NewToDomain(p.TagDotReplacement),
 		timeRangeIndices: getLoggingTimeRangeIndexFn(


nit: getLoggingTimeRangeIndexFn is a decorator here. Below we use another decorator addRemoteReadClusters, which is also always applied. I recommend moving addRemoteReadClusters to be attached here, instead of inside getTimeRangeIndexFn, to make getTimeRangeIndexFn easier to read.

yurishkuro · 2025-01-12T02:52:28Z

plugin/storage/es/spanstore/reader.go

@@ -119,10 +116,16 @@ type SpanReaderParams struct {
 // NewSpanReader returns a new SpanReader with a metrics.
 func NewSpanReader(p SpanReaderParams) *SpanReader {
 	maxSpanAge := p.MaxSpanAge
+	readAlias := ""
 	// Setting the maxSpanAge to a large duration will ensure all spans in the "read" alias are accessible by queries (query window = [now - maxSpanAge, now]).
 	// When read/write aliases are enabled, which are required for index rollovers, only the "read" alias is queried and therefore should not affect performance.
 	if p.UseReadWriteAliases {
 		maxSpanAge = rolloverMaxSpanAge


we should give rolloverMaxSpanAge a better name, like dawnOfTimeSpanAge.

yurishkuro · 2025-01-12T02:55:45Z

plugin/storage/es/spanstore/reader.go

-			archiveSuffix = archiveIndexSuffix
-		}
+func getTimeRangeIndexFn(readAlias string, remoteReadClusters []string) timeRangeIndexFn {
+	if readAlias != "" {


it seems like it broke the original logic. When aliases are used (whatever the prefix is) we always want to return a single index name, never fall back to timeRangeIndices. But in the current form that only happens if readAlias is not blank.

ah, I see why it works - because readAlias is never empty if p.UseReadWriteAliases == true. In this case I would recommend changing the condition to:

Suggested change

if readAlias != "" {

if useReadWriteAliases {

It requires an extra arg to the function, but it's much better representation of the reasons for the code branching.

plugin/storage/es/spanstore/reader.go

yurishkuro · 2025-01-12T03:03:06Z

plugin/storage/es/spanstore/reader_test.go

-	})
-}
-
-func TestSpanReader_ArchiveTraces_ReadAlias(t *testing.T) {


why remove this test? It seems it was counting on different index names, so useful to keep as backwards compatibility guard.

@yurishkuro Its because we don't concatenate the two inside the reader anymore. That logic is handled by the factory. If use_aliases is set and the read alias suffix is set, then we just use that suffix instead of concatenating the two.

could we model that by altering withArchiveSpanReader constructor? Specifically to test the condition where the indices become ***archive vs ***archive-read (which I understand happens depending on use_aliases being set or not). You don't have any significant changes to the tests for the factory, but that's where the distinction is being captured.

@yurishkuro That would just be a difference of changing ArchiveIndexSuffix to be archive vs archive-read because the span reader just respects what is passed in today. This test would need to go into the factory but there isn't a nice way to do that right now because the reader is a concrete type so we can't use a mock to see what is passed into the createSpanReader function. We could make some changes to make the create functions parameters so they can be injected for testing.

yurishkuro · 2025-01-12T03:05:05Z

plugin/storage/es/spanstore/writer.go

-		}
-	}
-
-	if p.UseReadWriteAliases {


similar to reader, please continue using this boolean condition instead of alias!=""

yurishkuro · 2025-01-12T03:06:13Z

plugin/storage/es/spanstore/reader.go

@@ -109,7 +106,7 @@ type SpanReaderParams struct {
 	SpanIndex           cfg.IndexOptions
 	ServiceIndex        cfg.IndexOptions
 	TagDotReplacement   string
-	Archive             bool
+	ReadAlias           string


Suggested change

ReadAlias string

ReadAliasSuffix string

let's be more precise, this code already has unnecessarily high complexity to complicate it further with inaccurate names

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 commented Jan 6, 2025

View reviewed changes

mahadzaryab1 changed the title ~~Remove Dependency on Archive Flag In ES Reader~~ [WIP][storage] Remove dependency on archive flag in ES reader Jan 6, 2025

mahadzaryab1 commented Jan 6, 2025

View reviewed changes

plugin/storage/es/factory.go Outdated Show resolved Hide resolved

yurishkuro reviewed Jan 6, 2025

View reviewed changes

plugin/storage/es/factory.go Show resolved Hide resolved

mahadzaryab1 force-pushed the es-archive-dependency branch from 20e7ccc to 944f4e0 Compare January 6, 2025 02:43

mahadzaryab1 commented Jan 6, 2025

View reviewed changes

plugin/storage/es/spanstore/reader.go Show resolved Hide resolved

yurishkuro reviewed Jan 6, 2025

View reviewed changes

plugin/storage/es/spanstore/reader.go Outdated Show resolved Hide resolved

mahadzaryab1 force-pushed the es-archive-dependency branch 2 times, most recently from 712c974 to 9adf03e Compare January 8, 2025 00:39

mahadzaryab1 added the changelog:bugfix-or-minor-feature label Jan 8, 2025

mahadzaryab1 commented Jan 8, 2025

View reviewed changes

yurishkuro reviewed Jan 8, 2025

View reviewed changes

plugin/storage/es/spanstore/writer_test.go Show resolved Hide resolved

mahadzaryab1 force-pushed the es-archive-dependency branch from 67145ac to 2f7a9be Compare January 8, 2025 03:53

mahadzaryab1 added 6 commits January 7, 2025 22:54

Use ReadWriteAliases Instead of Archive Flag

9d1d999

Signed-off-by: Mahad Zaryab <[email protected]>

Remove Archive Flag From Writer

4f5cad5

Signed-off-by: Mahad Zaryab <[email protected]>

Introduce New Arguments To Remove IsArchive Flag

af2e9ec

Signed-off-by: Mahad Zaryab <[email protected]>

Introduce New Arguments To Remove IsArchive Flag In Writer

904d3fb

Signed-off-by: Mahad Zaryab <[email protected]>

Fix Tests

6bc1ebf

Signed-off-by: Mahad Zaryab <[email protected]>

Update Callsites

0ae679d

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 force-pushed the es-archive-dependency branch from 2f7a9be to 0ae679d Compare January 8, 2025 03:56

mahadzaryab1 added 2 commits January 7, 2025 23:13

Propagate Arguments To Archive Constructor

c0ea9a2

Signed-off-by: Mahad Zaryab <[email protected]>

Handle Archive And Use Aliases Both Set

5659221

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 commented Jan 8, 2025

View reviewed changes

mahadzaryab1 added 4 commits January 9, 2025 18:19

Fix Branching In Reader And Change Variable Name

52f63fd

Signed-off-by: Mahad Zaryab <[email protected]>

Fix Branching In Writer And Change Variable Name

c573a66

Signed-off-by: Mahad Zaryab <[email protected]>

Fix Variable Naming

4976f7b

Signed-off-by: Mahad Zaryab <[email protected]>

Move Check To Constructor

77d47c0

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 requested a review from yurishkuro January 10, 2025 00:47

dosubot bot added the area/storage label Jan 10, 2025

yurishkuro reviewed Jan 10, 2025

View reviewed changes

mahadzaryab1 commented Jan 10, 2025

View reviewed changes

yurishkuro reviewed Jan 11, 2025

View reviewed changes

mahadzaryab1 force-pushed the es-archive-dependency branch from a392964 to 00e90a9 Compare January 11, 2025 21:46

mahadzaryab1 force-pushed the es-archive-dependency branch from 00e90a9 to 6137308 Compare January 11, 2025 23:02

mahadzaryab1 added 2 commits January 11, 2025 18:06

Remove Indirection In getSourceFn

2bf4a61

Signed-off-by: Mahad Zaryab <[email protected]>

Fix Linting

6cf08e8

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 force-pushed the es-archive-dependency branch from 07c5976 to 6cf08e8 Compare January 11, 2025 23:06

Merge branch 'main' into es-archive-dependency

77ca3c3

Signed-off-by: Mahad Zaryab <[email protected]>

Fix Lint

686cc8d

Signed-off-by: Mahad Zaryab <[email protected]>

Merge branch 'main' into es-archive-dependency

b6db77a

mahadzaryab1 requested a review from yurishkuro January 12, 2025 00:51

Merge branch 'main' into es-archive-dependency

20f5f5d

yurishkuro reviewed Jan 12, 2025

View reviewed changes

yurishkuro mentioned this pull request Jan 12, 2025

[refactor] Seperated the parts of ES-Rollover Config common with ES Config #6516

Open

4 tasks

Address Feedback From PR Review

b785631

Signed-off-by: Mahad Zaryab <[email protected]>

mahadzaryab1 requested a review from yurishkuro January 12, 2025 03:40

		}
		return archiveIndex(spanIndexPrefix, archiveIndexSuffix), ""

		@@ -136,9 +139,9 @@ func NewSpanReader(p SpanReaderParams) *SpanReader {
		spanConverter: dbmodel.NewToDomain(p.TagDotReplacement),
		timeRangeIndices: getLoggingTimeRangeIndexFn(

[storage] Remove dependency on archive flag in ES reader #6490

Are you sure you want to change the base?

[storage] Remove dependency on archive flag in ES reader #6490

Conversation

mahadzaryab1 commented Jan 6, 2025 • edited Loading

Which problem is this PR solving?

Description of the changes

How was this change tested?

Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mahadzaryab1 commented Jan 6, 2025

codecov bot commented Jan 6, 2025 • edited Loading

Codecov Report

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

mahadzaryab1 Jan 9, 2025 • 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

mahadzaryab1 Jan 10, 2025 • 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

mahadzaryab1 commented Jan 11, 2025 • edited Loading

yurishkuro commented Jan 11, 2025

mahadzaryab1 commented Jan 11, 2025 • edited Loading

yurishkuro commented Jan 11, 2025

mahadzaryab1 commented Jan 11, 2025

yurishkuro commented Jan 11, 2025

mahadzaryab1 commented Jan 11, 2025 • edited Loading

yurishkuro commented Jan 11, 2025

mahadzaryab1 commented Jan 11, 2025 • edited Loading

mahadzaryab1 commented Jan 11, 2025

yurishkuro 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

mahadzaryab1 Jan 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mahadzaryab1 commented Jan 6, 2025 •

edited

Loading

codecov bot commented Jan 6, 2025 •

edited

Loading

mahadzaryab1 Jan 9, 2025 •

edited

Loading

mahadzaryab1 Jan 10, 2025 •

edited

Loading

mahadzaryab1 commented Jan 11, 2025 •

edited

Loading

mahadzaryab1 commented Jan 11, 2025 •

edited

Loading

mahadzaryab1 commented Jan 11, 2025 •

edited

Loading

mahadzaryab1 commented Jan 11, 2025 •

edited

Loading

mahadzaryab1 Jan 12, 2025 •

edited

Loading