[redisstorageextension] allow redis key prefix to be specified in config

[HubertFraczek]

Description

The purpose of this PR is to allow the user to specify the redis key prefix. The lack of this feature has become problematic when using multiple replicas in a kubernetes cluster - until now, the key prefix has been based on the storage extension and receiver names, which are the same for each replica because they share the same configuration and therefore overwrite the same key in redis. With the changes in this PR, the user can specify the prefix as an environmental variable (which can have different value for each replica), for example.

Testing

opentelemetry-collector-contrib (0.118.0) was built with this change and tested on a kubernetes cluster

Config used for testing:

redis_storage:
  endpoint: redis.monitoring.svc.cluster.local:6379
  prefix: ${K8S_NODE_NAME}

Documentation

Updated README.md to add new config parameter.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: HubertFraczek / name: Hubert Frączek (a270e3f, 3ba5fb9, 6bda059, 6d8cc31)
• ✅ login: atoulme / name: Antoine Toulme (e364460, 38a4f9e)

[origama]

Hey guys, is there any process to follow to get the PR reviewed? Or is it just a matter of time?

[swiatekm]

Could you update the documentation with the new semantics as well?

[swiatekm]

@HubertFraczek you're going to need to add a changelog entry as well. Try running make chlog-new in the project root and fill in the template it creates for you.

[swiatekm]

LGTM, thank you for the contribution!

[atoulme]

build fails with

Error: redisstorageextension/extension_test.go:248:4: expected-actual: need to reverse actual and expected values (testifylint)
			require.Equal(t, got, tt.expected)
			^

Please address and we will get this in.

[HubertFraczek]

Is there anything left for me to do? I also wanted to ask if these changes will appear in the next release

[swiatekm]

Is there anything left for me to do? I also wanted to ask if these changes will appear in the next release

You just need to address review comments as they come, and after there's sufficient approvals, your PR will be merged. The change will appear in whichever release happens afterwards. Releases happen every 2 weeks, so you typically don't need to wait for long.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[HubertFraczek]

Hi, what is the progress with this PR? Is the fix for that failing unit test from that other extension merged to main? Can we re-run pipelines and merge this PR in?